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Foreword 

This Technical Specification (TS) has been produced by IMS Network Testing (INT). 

The present document is part 2 of a multi-part deUverable covering the IMS NNI Interworking Test Specifications, as 
identified below: 

Part 1 : "Test purposes for IMS NNI Interoperability"; 

Part 2: "Test descriptions for IMS NNI Interoperability"; 

Part 3: "Abstract Test Suite (ATS) and partial Protocol Implementation eXtra Information for Testing (PIXIT)". 
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Scope 



The present document specifies interoperability Test Descriptions (TDs) for IMS NNI interoperability testing for the IP 
Multimedia Call Control Protocol based on Stage 3 Session Initiation Protocol (SIP) and Session Description Protocol 
(SDP) standard, TS 124 229 [1]. TDs have been specified on the basis of the Test Purposes (TPs) and Test Suite 
Structure (TSS) presented in TS 186 011-1 [2]. TP fragments presented in the present document as part of TDs are 
defined using the TPLan notation of ES 202 553 [5]. TDs have been written based on the test specification framework 
described in TS 102 351 [3] and the interoperability testing methodology defined in TS 102 237-1 [4], 
i.e. interoperability testing with a conformance relation. 

For the assessment of IMS core network requirements related to the ISC interface parts of the supplementary services 
HOLD (see TS 124 410 [10]), CDIV (see TS 124 404 [11]), ACR-CB (see TS 124 41 1 [12]) and OIP/OIR 
(see TS 124 407 [13]) have been used. 

The scope of these test descriptions is not to cover all requirements specified in TS 124 229 [1]. TDs have been only 
specified for requirements that are observable at the interface between two IMS core network implementations, i.e. IMS 

NNI. 

NOTE: Requirements pertaining to a UE or an AS implementation or IMS core network requirements that can 
only be observed at the interface between UE and IMS CN are explicitly not within the scope of the 
present document. The latter requirements have been dealt with from a UE and conformance perspective 
inTS 134 229 [6]. 



2 References 

References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• Non-specific reference may be made only to a complete document or a part thereof and only in the following 

cases: 

if it is accepted that it will be possible to use all future changes of the referenced document for the 
purposes of the referring document; 

for informative references. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were vahd at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are indispensable for the application of the present document. For dated 
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document 
(including any amendments) applies. 

[1] ETSI TS 124 229: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); LTE; Internet Protocol (IP) multimedia call control 
protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); 
Stage 3 (3GPP TS 24.229 version 7.14.0 Release 7)". 

[2] ETSI TS 186 011-1 (V2.0.0): "Technical Committee for IMS Network Testing (INT); IMS NNI 

Interoperability Test Specifications; Part 1: Test purposes for IMS NNI Interoperability". 
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[3] ETSI TS 102 35 1 : "Methods for Testing and Specification (MTS); Internet Protocol Testing (IPT); 

IPv6 Testing: Methodology and Framework". 

[4] ETSI TS 102 237-1: "Telecommunications and Internet Protocol Harmonization Over Networks 

(TIPHON) Release 4; Interoperability test methods and approaches; Part 1 : Generic approach to 
interoperability testing". 

[5] ETSI ES 202 553: "Methods for Testing and Specification (MTS); TPLan: A notation for 

expressing Test Purposes". 

[6] ETSI TS 134 229 (all parts): "Universal Mobile Telecommunications System (UMTS); Internet 

Protocol (IP) multimedia call control protocol based on Session Initiation Protocol (SIP) and 
Session Description Protocol (SDP)". 

[7] ETSI TS 133 203: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); 3G security; Access security for IP-based services 
(3GPP TS 33.203 Release 7)". 

[8] IETF RFC 2617: "HTTP Authentication: Basic and Digest Access Authentication". 

[9] IETF RFC 3966: "The tel URI for Telephone Numbers". 

[10] ETSI TS 124 410: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); TISPAN; NGN Signalling Control Protocol; 
Communication HOLD (HOLD) PSTN/ISDN simulation services; Protocol specification 
(3GPP TS 24.410 Release 7)". 

[11] ETSI TS 124 404: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); TISPAN; PSTN/ISDN simulation services: 
Communication Diversion (CDIV); Protocol specification (3GPP TS 24.404 Release 7)". 

[12] ETSI TS 124 411: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); TISPAN; PSTN/ISDN simulation services: Anonymous 
Communication Rejection (ACR) and Communication Barring (CB); Protocol specification 
(3GPP TS 24.411 Release 7)". 

[13] ETSI TS 124 407: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); TISPAN; PSTN/ISDN simulation services; Originating 
Identification Presentation (OIP) and Originating Identification Restriction (OIR); Protocol 
specification (3GPP TS 24.407 Release 7)". 

[14] ETSI TS 183 063: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); IMS-based IPTV stage 3 specification". 

[15] ETSI TS 124 141: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); LTE; Presence service using the IP Multimedia (IM) Core 
Network (CN) subsystem; Stage 3 (3GPP TS 24.141 Release 7)". 

2.2 Informative references 

The following referenced documents are not essential to the use of the present document but they assist the user with 
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including 
any amendments) applies. 

[i.l] ETSI TR 133 978: "Universal Mobile Telecommunications System (UMTS); Security aspects of 

early IP Multimedia Subsystem (IMS) (3GPP TR 33.978 version 7.0.0 Release 7)". 

[i.2] ETSI TR 123 981: "Universal Mobile Telecommunications System (UMTS); Interworking aspects 

and migration scenarios for IPv4-based IP Multimedia Subsystem (IMS) implementations 
(3GPP TR 23.981 Release 7)". 
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Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

3GPP 3'''^ Generation Partnership Project 

ACR Anonymous Communication Rejection 

AKA Authentication and Key Agreement 

AS (IMS) Application Server 

BC Broadcast 

CB Call Barring 

CDIV Call Diversion 

CF (Test) ConFiguration 

CFU Call Forward Unconditional 

CFW Call Flow 

CN Core Network 

CoD Content on Demand 

CSCF Call Session Control Function 

DHCP Dynamic Host Configuration Protocol 

DNS Domain Name System 

ENUM E. 1 64 Number Mapping 

HOLD Communication HOLD 

HSS Home Subscriber Server 

IBCF Interconnection Border Control Gateway 

I-CSCF Interrogating CSCF 

IMS IP Multimedia Subsystem 

lOI Inter Operator Identifier 

IP Internet Protocol 

IPsec Internet Protocol security 

IPTV IP Television 

ISC IMS Service Control 

MGCF Media Gateway Control Function 

MGF Media Gateway Function 

MRFC Multimedia Resource Function Controller 

MRFP Multimedia Resource Function Processor 

NNI Network-to-Network Interface 

N-PVR Network based Personal Video Recording 

OCB Outgoing Communication Barring 

OIP Originating Identification Presentation 

OIR Originating Identification Restriction 

PCO Point of Control and Observation 

P-CSCF Proxy CSCF 

PO Point of Observation 

PSTN Public Switched Telephone Network 

SA Security Association 

S-CSCF Serving CSCF 

SDP Session Description Protocol 

SIP Session Initiation Protocol 

SGF Signalling Gateway Function 

SUT System Under Test 

TCP Transmission Control Protocol 

TD Test Description 

TISPAN Telecommunications and Internet converged Services and Protocols for Advanced Networking 

TP Test Purpose 

TPLan Test Purpose Notation 

TSS Test Suite Structure 

UC Use Case 

UE User Equipment 

URI Uniform Record Identifier 

VoIP Voice over Internet Protocol 

XML Extensible Markup Language 
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IMS NNI Interoperability Test Specification 



4.1 



Introduction 



The IMS NNI Interoperability Test Descriptions (TDs) defined in the following clauses are derived from the Test 
Purposes (TPs) specified in TS 186 011-1 [2]. The TDs cover both basic call procedures such as call establishment and 
call release and a selection of the most common supplementary services. 



4.2 Test Prerequisites 



4.2.1 



IP Version 



These test specifications are based on the use of IPv4 for SIP message transport throughout all IMS nodes as specified 
in TR 123 981 [i.2]. 

4.2.2 Authentication and Security 

The current test specification supports as default full IMS TS 133 203 [7] 3GPP security. Non-compliance with full 
IMS security features defined in TS 133 203 [7] is expected to be a problem mainly at the UE side, because of the 
potential lack of support of the USIM/ISIM interface (especially in 2G-only devices) and of the potential inability to 
support IPsec on some UE platforms. For those reasons, fallback to early IMS TR 133 978 [i.l] and SIP Digest 
authentication without key agreement and null authentication may be used to achieve satisfactory test results. Tests 
should however be executed with full IMS security if all required IMS nodes support it. 

4.2.3 Registration and Subscription 
4.2.3.1 SIP Call Flow 

This clause describes the registration call flow under the authentication and security scope described in clause 4.2.2. 



4.2.3.1.1 



Early IMS Registration and Subscription Call Flow 



Early IMS security does not allow SIP requests to be protected using an IPsec Security Association (SA) because it does 
not perform a key agreement procedure. IPsec security associations are not set up between UE and P-CSCF, as they are 
in the full IMS security solution. For early IMS security, the expected registration and subscription sequence is: 



Step 


Direction 


Message 


Comment 




UE 1 IMS 




1 






The UE establishes an IP bearer as required by its 
specific access networl< (optional). 




2 


^^ 




P-CSCF address discovery using DHCP 
procedures for IPv4 (optional). 




3 


-> 


REGISTER 


The UE sends initial registration for IMS services. 


0) 

O 

Q. 

c 
Z) 


4 


^ 


200 OK 


The IMS responds with 200 OK. 


5 


^ 


SUBSCRIBE 


The UE subscribes to its registration event 
package. 


6 


^ 


200 OK or 202 Accepted 


The IMS responds with 200 OK or 202 Accepted. 


7 


^ 


NOTIFY 


The IMS sends initial NOTIFY for registration event 
package, containing full registration state 
information for the registered public user identity in 
the XML body. 


8 


^ 


200 OK 


The UE responds with 200 OK. 
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4.2.3.1.2 



Full IMS Registration and Subscription Call Flow 



For full IMS security, the expected registration and subscription sequence is: 



Step 


Direction 


IVIessage 


Comment 




UE 1 IIUIS 




1 






The UE establishes an IP bearer as required by its 
specific access network (optional). 




2 


^-> 




P-CSCF address discovery using DHCP 
procedures for IPv4 (optional). 




3 


^ 


REGISTER 


The UE sends initial registration for IMS services. 


T3 

B 

O 

S 
o 

3 


4 


<- 


401 Unauthorized 


The IMS responds with a valid Digest AKA 
authentication challenge and a list of integrity and 
encryption algorithms supported by the network as 
defined in the IMS AKA procedure of 
TS 133 203 [7]. 


5 






Upon receipt of 401 Unauthorized, the UE selects 
the first integrity and encryption algorithm 
combination on the list received from the P-CSCF in 
401 Unauthorized which is also supported by the 
UE. If the P-CSCF did not include any 
confidentiality algorithm in 401 Unauthorized then 
the UE shall select the NULL encryption algorithm. 
The UE then proceeds to establish two new pairs of 
IPSEC Security Associations (SA1 and SA2). 




6 


■^ 


REGISTER 


The UE sends another REGISTER with 
authentication credentials over IPSEC security 
association SA1 . 


< 
W 

>, 

■a 

0) 

o 
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£ 
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^ 


200 OK 


The IMS responds with 200 OK over the same 
IPSEC security association SA1 . 


8 


-» 


SUBSCRIBE 


The UE subscribes to its registration event package 
over the IPSEC security association SA2. 


CM 
< 

>, 

■a 

B 

O 
CD 
O 
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«- 


200 OK or 202 Accepted 


The IMS responds with 200 OK or 202 Accepted 
over the IPSEC security association SA2. 


10 


^ 


NOTIFY 


The IMS sends initial NOTIFY for registration event 
package, containing full registration state 
information for the registered public user identity in 
the XML body, over the IPSEC security association 
SA2. 


11 


^ 


200 OK 


The UE responds with 200 OK over the IPSEC 
security association SA2. 
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4.2.3.1.3 



SIP Digest Registration and Subscription Call Flow 



For SIP Digest authentication without key agreement and null authentication, the expected registration and subscription 
sequence is: 



Step 


Direction 


Message 


Comment 




UE 1 IMS 




1 






The UE establishes an IP bearer as required by its 
specific access networl< (optional). 




2 


^^ 




P-CSCF address discovery using DHCP 
procedures for IPv4 (optional). 




3 


^ 


REGISTER 


The UE sends initial registration for IMS services. 


T3 

S 
O 
0) 

O 

Q. 

Z) 


4 


^ 


401 Unauthorized 


The IMS responds with a valid HTTP Digest 
authentication challenge as defined in 
RFC 2617 [8]. 


5 


^ 


REGISTER 


The UE sends another REGISTER with 
authentication credentials. 


6 


^ 


200 OK 


The IMS responds with 200 OK. 


7 


^ 


SUBSCRIBE 


The UE subscribes to its registration event 
package. 


8 


^ 


200 OK or 202 Accepted 


The IMS responds with 200 OK or 202 Accepted. 


9 


^ 


NOTIFY 


The IMS sends initial NOTIFY for registration event 
package, containing full registration state 
information for the registered public user identity in 
the XML body. 


10 


■^ 


200 OK 


The UE responds with 200 OK. 



4.2.4 Supported Options 



4.2.4.1 



Security 



Support for security agreement is optional in case of Full IMS Reg. It shall only be used in case all IMS nodes support 
it. 



4.2.4.2 



Signalling Compression 



"No SigComp" is the default signalling configuration in all test descriptions. Tests may be executed with signalling 
compression if the required nodes support it. 



4.3 



Test Infrastructure 



In these clauses we define the involvement of the various IMS nodes specifically as they pertain to NNI testing. The 
configuration of the nodes is described. Points of control and observation are identified and static test configurations are 
described. The Mw interface or the Ic interface if topology hiding is required is the interface under observation for NNI 
interoperability testing. 

4.3.1 Core IMS Nodes 

Because the current testing scope excludes IMS roaming and border control functionality, P-CSCF, S-CSCF, I-CSCF, 
IBCF and HSS are considered to be within a "black box" for testing purposes, i.e. the System Under Test (SUT). 
Interfaces within the IMS are considered internal and not observable for testing purposes. 
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4.3.1.1 P-CSCF 

4.3.1.1.1 Relevant Interfaces 

The P-CSCF constitutes the point of entry for UE signalling into the IMS core. The Gm interface between the P-CSCF 
and the UE is used as a point of control and observation (PCO) for NNI interoperability testing purposes. In the case of 
IMS roaming configurations where no topology hiding is applied the Mw interface of the P-CSCF is exposed at the NNI 
and used there as a point of observation (PO). 

4.3.1.1.2 Node Configuration 

The P-CSCF should be configured to support the pre-requisites outlined in clause 4.2. 

4.3.1.2 S-CSCF 

4.3.1.2.1 Relevant Interfaces 

The S-CSCF is the core IMS node delivering IMS services to subscribers. When no topology hiding is applied, the Mw 
interface between the S-CSCF and either I- or S-CSCF in another network domain is used as a PO against which NNI 
interoperability tests are validated. The Mw interfaces between I- and S-CSCFs within the same network are considered 
to be internal IMS interfaces. Although considered as internal and not explicitly involved in all NNI test configurations, 
it is recommended that these interface are exposed for troubleshooting purposes. 

4.3.1.2.2 Node Configuration 

The S-CSCF should be configured to support the pre-requisites outlined in clause 4.2. When applicable based on the 
specific configuration, the S-CSCF must be provisioned to support required Application Servers (AS) as trusted nodes. 

4.3.1.3 l-CSCF 

4.3.1.3.1 Relevant Interfaces 

The I-CSCF is the contact point within an operator's network for all connections destined to a user of that network 
operator, or a roaming user currently located within that network operator's service area. When no topology hiding is 
applied, the Mw interface between the I-CSCF and an S-CSCF in another network domain is used as a PO against 
which NNI interoperability tests are validated. The Mw interfaces between I- and S-CSCFs within the same network are 
considered to be internal IMS interfaces. Although considered as internal and not explicitly involved in all NNI test 
configurations, it is recommended that these interface are exposed for troubleshooting purposes. 

4.3.1.3.2 Node Configuration 

The I-CSCF should be configured to support the pre-requisites outlined in clause 4.2. 

4.3.1.4 IBCF 

4.3.1.4.1 Relevant Interfaces 

The IBCF is the core IMS node providing functionalities such as topology hiding, transport plane control or screening 
of SIP signalling. However, the IBCF can act also as a pass-through entity between adjacent IMS networks. The Ic 
interface between the IBCF and either IBCF or I- or S-CSCF in another network domain is used as a PO against which 
NNI interoperability tests are validated. The Mw interfaces between IBCF and I- or S-CSCFs within the same network 
are considered to be internal IMS interfaces. Although considered as internal and not explicitly involved in all NNI test 
configurations, it is recommended that these interfaces are exposed for troubleshooting purposes. 
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4.3.1.4.2 



Node Configuration 



The IBCF should be configured to support the pre-requisites outlined in clause 4.2. The need to activate the IBCF as 
part of an IMS core network depends highly on the test description to be executed. In case the requirement to support 
topology hiding is not explicitly stated in the pre-conditions of a test description it shall be assumed that the IBCF is not 
activated and acts merely as a pass-through entity. 



4.3.1.5 



HSS 



4.3.1.5.1 



Relevant Interfaces 



The HSS constitutes the repository for IMS subscriber information. The Cx interface between the HSS and the S-CSCF 
and/or I-CSCF is considered an internal IMS interface. 



4.3.1.5.2 



Node Configuration 



The HSS should be configured within each IMS participating in an interoperability test, i.e. IMS_A as well as IMS_B, 
to interact with CSCFs as required using DIAMETER Cx interfaces. Users should be provisioned to match the sample 
profiles listed in table 1 . In addition, each IMS shall have its own unique domain. Also the phone numbers configured in 
the two IMSes participating in an interoperability test shall be unique, i.e. IMS_A and IMS_B shall have no phone 
numbers in common. All public identities belong to the same implicitly registered set. 

Table 1 : HSS sample user profiles 



Private Identity 


Public Identity 1 
(SIP URI) 


Public Identity 2 
(Tel URI) 


Default 
Public 
Identity 


Filter criteria 


userGEN priv 


userGEN 


na 


1 


na 


users IP jDriv 


userSIP 


e.g. tel:+3301 23402 


1 


na 


userTEL priv 


userTEL 


e.g. tel:+3301 23403 


2 


na 


userNOAS_priv 


userNOAS 


na 


1 


contact AS on terminating INVITE 
SESSION TERMINATED 


userHOLD priv 


userHOLD 


na 


1 


contact HOLD AS 


userOIP priv 


userOIP 


na 


1 


contact OIP AS 


userOIR priv 


userOIR 


na 


1 


contact OIR AS 


userACR priv 


userACR 


na 


1 


contact ACR AS 


userCFU priv 


userCFU 


na 


1 


contact CFU AS 


userPRES priv 


userPRES 


na 


1 


contact Presence AS 


userlPTV priv 


userlPTV 


na 


1 


Contact IPTV AS 



Public user identity may take the form of SIP or TEL URIs (RFC 3966 [9]). 

EXAMPLE 1: sip: userGEN@ims_a.net. 

EXAMPLE 2: tel: H-330123402. 
A private user identity may also take the form of- <imsi>@ims.<xxx>mnc.<yyy>. mcc.3gppnetwork.org. 

EXAMPLE 3: 293410100367663@ims.041mnc.293.mcc.3gppnetwork.org . 



4.3.1.6 



MRFC 



4.3.1.6.1 



Relevant Interfaces 



4.3.1.6.2 



Node Configuration 



The MRFC should be configured to support the pre-requisites outlined in clause 4.2. The need to activate the MRFC as 
part of an IMS core network depends highly on the test description to be executed. In case the requirement to support 
topology hiding is not explicitly stated in the pre-conditions of a test description it shall be assumed that the MRFC is 
not activated. 
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4.3.1.7 MRFP 

4.3.1.7.1 Relevant Interfaces 

4.3.1.7.2 Node Configuration 

The MRFP should be configured to support the pre-requisites outhned in clause 4.2. The need to activate the MRFP as 
part of an IMS core network depends highly on the test description to be executed. In case the requirement to support 
topology hiding is not explicitly stated in the pre-conditions of a test description it shall be assumed that the MRFP is 
not activated. 

4.3.1.8 MGCF 

4.3.1.8.1 Relevant Interfaces 

4.3.1.8.2 Node Configuration 

The MGCF should be configured to support the pre-requisites outlined in clause 4.2. The need to activate the MGCF as 
part of an IMS core network depends highly on the test description to be executed. In case the requirement to support 
topology hiding is not explicitly stated in the pre-conditions of a test description it shall be assumed that the MGCF is 
not activated. 

4.3.1.9 MGF 

4.3.1.9.1 Relevant Interfaces 

4.3.1.9.2 Node Configuration 

The MGF should be configured to support the pre-requisites outlined in clause 4.2. The need to activate the MGF as 
part of an IMS core network depends highly on the test description to be executed. In case the requirement to support 
topology hiding is not explicitly stated in the pre-conditions of a test description it shall be assumed that the MGF is not 
activated. 

4.3.1.10 SGF 

4.3.1.10.1 Relevant Interfaces 

4.3.1.10.2 Node Configuration 

The MGCF should be configured to support the pre-requisites outlined in clause 4.2. The need to activate the SGF as 
part of an IMS core network depends highly on the test description to be executed. In case the requirement to support 
topology hiding is not explicitly stated in the pre-conditions of a test description it shall be assumed that the SGF is not 
activated. 

4.3.2 External IMS Nodes 

4.3.2.1 UE 

4.3.2.1.1 Relevant Interfaces 

The UE is considered to act as a stimulus node in this test specification. The Gm interface between the P-CSCF and the 
UE is used as a Point of Control and Observation (PCO) for NNI interoperability tests. 
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4.3.2.1.2 Node Configuration 



The UE should be configured to support the pre-requisites outhned in clause 4.2. The test descriptions in the present 
document assume that a UE supports basic call and messaging functionality, target refresh based on UPDATE and on 
re-INVITE method, message transport via UDP and TCP and the use of at least one of the supplementary services 
HOLD (see TS 124 410 [10]), CDIV (see TS 124 404 [11]), ACR-CB (see TS 124 41 1 [12]) or OIP/OIR 
(see TS 124 407 [13]). In the case that a UE does not meet one or more of these features, only a selected subset of the 
test descriptions in this document should be used for IMS core network interoperability testing, i.e. test descriptions 
which do not contain any pass criteria related to these features. 

4.3.2.2 AS 

4.3.2.2.1 Relevant Interfaces 

The Application Server (AS) is considered to act as a stimulus node in this test specification. The ISC interface between 
the S-CSCF and the AS is used as a Point of Control and Observation (PCO) for NNI interoperability tests. 

4.3.2.2.2 Node Configuration 

The AS should be configured to support the pre-requisites outlined in clause 4.2. The test descriptions in the present 
document assume that an AS supports the use of the supplementary services HOLD (see TS 124 410 [10]), CDIV 
(see TS 124 404 [11]), ACR-CB (see TS 124 41 1 [12]) and OIP/OIR (see TS 124 407 [13]). In the case that an AS does 
not support one or more of these supplementary services, only a selected subset of the test descriptions in the present 
document should be used for IMS core network interoperability testing, i.e. test descriptions which do not contain any 
pass criteria related to these supplementary services. 

4.3.3 Supporting IMS Nodes 
4.3.3.1 DNS 

4.3.3.1.1 Relevant Interfaces 

The Domain Name Service (DNS) is considered as a supporting entity in this test specification. It is assumed that each 
IMS has its own local DNS which is connected to the common interconnect DNS. 

4.3.3.1.2 Node Configuration 

The common DNS should be configured for appropriate resource record handling as required to support proper 
resolution of all SIP URIs in Request URIs and Route headers. In addition, either the local or common DNS must 
support ENUM functionality in order to resolve Tel URIs into SIP URIs. As an example, a DNS should have an entry to 
map E.164 number 0633348273 to the SIP URI of userSIP. 

4.3.4 Test Configurations 

The following architectural test configurations are referenced in the IMS NNI interoperability TDs in the present 
document. They are intended to give a general rather than a specific view of the required IMS core network SUT(s) 
connectivity and associated UE(s), AS(s) and DNS(s). 

NOTE: In the following figures observable interfaces are indicated as a solid line, non-observable interfaces 

indicated as dashed lines and IBCFs are assumed to act in a "pass-through" mode if topology hiding is not 
required by a test description. In addition, local DNS servers are not shown. 
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Roaming Registration 
CF ROAM REG 



UE 



Gm 







PCO 



IMS A 



HSS 



P-CSCF 



l-CSCF 



S-CSCF 



IBCF 



Mw 







HSS 



IMSB 



S-CSCF 



IBCF 





P-CSCF 


''.. 






l-CSCF 
V 



PO 

Precondition: 

Different network operators performing origination and termination, UE_B roaming in Home network A 

(ROAM), UE_B not yet registered (REG), neither UE_A nor AS involved, IBCF may be involved 
Test configuration for: 

Registration requests and responses from UE_B 
Example: 

REGISTER pnor to IMS VoIP voice call from UE_B 

Figure 1 : CF_ROAM_REG 

Intenfl/orkJng Call 
CF INT CALL 
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l-CSCF 
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1 






u 



























Gm 



[^- 



UE 
B 



PCO 



PO 

Precondition: 

Different network operators performing origination and termination, both UEs or only UE A in home 
networks (INT), both UE's registered, AS may be involved, a common interconnect DNS and local 
DNSs for each IMS may be involved, IBCF may be involved 

Test configuration for: 

Requests and responses between UE_A and UE_B in call (CALL) and messaging scenarios 
Unsuccessful initial requests and responses from UE_A (when UE_B is not registered) 

Example: 

Initial INVITE in IMS VoIP voice call from UE_Ato UE_B 

Figure 2: CF_INT_CALL 
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UE 
A 



UE 
B 



^ \ 

UE 



Gm 







Roaming Call 
CF ROAM CALL 



Gm 






PCO 
Gm 



^; 



PCO 



IMS A 



HSS 



P-CSCF 



l-CSCF 



S-CSCF 



IBCF 



Mw 



t 



HSS 



IMSB 



S-CSCF 



P-CSCF 



IBCF 



I 

V > 



l-CSCF 



PO 

Precondition: 

Different network operators performing origination and termination, UE_B roaming (ROAM) via 

IMS_A, UE_A in home network, both UEs are registered, no AS, IBCF may be involved 
Test configuration for: 

Requests and responses between UEB and UE_A in call (CALL) and messaging scenarios 
Example: 

Initial INVITE in IMS VoIP voice call from UE_B to UE_A 

Figure 3: CF_ROAM_CALL 

I nterworklng Application Server 
CF INT AS 



PCO 
ISC 



AS 
A 



1^1 



PCO 



IMS A 



HSS 



P-CSCF 



l-CSCF 



S-CSCF 




Mw 







PO 



HSS 



^ S-CSCF ^ 



IMSB 



' P-CSCF ^ 




l-CSCF 



Gm 







PCO 
ISC 



m 



/■ ^ 

UE 
B 



AS 
B 



PCO 



Precondition: 

Different network operators peri'orming origination andtermination,UE_AandUE_Bin home networks 

(INT), both UEs registered, ASesfor UE_A and UE_B (AS), IBCF may be involved 
Test configuration for: 

Requests and responses between ASesandUEs 
Example: 

Initial INVITE in IMS VoIP voice call unconditionally forwarded to UE_B by AS_A (CFU). AS_A acts 

as routing AS 

Figure 4: CF_INT_AS 
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UE 
A 



UE 



Roaming Application Server 
CF ROAM AS 



Gm 



Dr-n > 



PCO 
Gm 




PCO 



IMS A 



P-CSCF 




S-CSCF 






l-CSCF 



IBCF 
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Mw 
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HSS 
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IBCF 
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P-CSCF 



^ 



l-CSCF K 



ISC 



fl 



PCO 



AS 
B 



PO 



Precondition: 

Different network operators performing origination and termination, UE_B roaming (ROAM) via 

IMS_A, UE_A in home network, both UEs or registered, AS for UE_A and UE B may be involved 

(AS), IBCF may be involved 
Test configuration for: 

Requests and responses bebveen AS_B and UEs 

Unsuccessful Initial requests and responses from UE_A (when UE_B and AS_B are not available) 
Example: 

Initial INVITE IMS VoIP voice call unconditionally forwarded to UE_B by AS_B (CPU). AS_B acts 

as routing AS 

Figure 5: CF_ROAM_AS 
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S-CSCF 



l-CSCF 



P-CSCF 
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MRFC 
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UE 
B 
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Precondition: 

Different network operators performing origination and termination, both UEs or only UE A In home 

networks (INT), both UE's registered, CONF AS Is involved In IMS A, IMS A and IMS B both Include 

MRFC and MRFP 
Test configuration for: 

Requests and responses between UEA and UEB In an Ad-Hoc Conference Call (CONFCALL) 
Example: 

Initial INVITE In from UE_Ato Initiate an Ad-Hoc Conference call In IMS A, and subsequent Invitation 

to UE_B to join (via REFER method from UE_A) 

Figure 6: CF_INT_CONF_CALL 
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IPTV 

CF IPTV 



UE 
A 



Gm 



^ 



PCO 



IMS A 



l-CSCF 



HSS 



P-CSCF S-CSCF 



^ PCO 



[ IBCF 1 



ISC 



IPTV 
AS 



Precondition: 

UE A registered in home network, IPTV-AS is involved 
Test configuration for: 

Requests and responses between UE_A and AS_A 
Example: 

Initial INVITE from UE_A to AS_A to initiate a IPTV Broadcast session. 

Figure 7: CFJPTV 



IMS-PSTN Call 
CF PSTN 
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Legacy Network 
(PSTN) 



f POTS/ K 
_y ISDN \) 

w 



Precondition: 

Single network with UE in home networks and registered, AS and l-CSCF may be involved 
Test configuration for: 

Requests and responses between UE and POTS or ISDN phone 
Example: 

Initial INVITE from UE to POTS phone 

Figure 8: CF_PSTN 
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4.4 



Use Cases 



Use cases are the basis for interoperability test descriptions. Each use case defines both a generic test sequence, i.e. a set 
of user stimuli and observations for any number of involved IMS external entities (IMS UE, DNS Server and AS) and a 
monitor view of all the resulting messages exchanged at the outer IMS core network interfaces, i.e. a call flow for user, 
Gm, Mw, Ic, DNS and ISC interfaces. The test sequence and call flow are correlated using grey shading. 

For call and messaging related use cases presented in this clause that involve UE interaction it is assumed to follow the 
registration and subscription procedure described in clause 4.2.4 for each UE involved in the test. These procedures are 
not shown here to reduce the size of the call flows. 

Test descriptions defined in clause 4.5 then reference and specialize one of the use cases presented in this clause, 
i.e. generic test sequence and call flow, according to the needs of the one or more test purposes which are associated 
with a test description. 

4.4.1 IMS Registration in a Visited Networl< 



4.4.1.1 



Description 



UE_B registers in a visiting network. The call flow path and node configuration for this use case corresponds to 
CF_ROAM_REG. 

The test sequence typically associated with this use case when an established session is released is as follows (CFW 
step numbers refer the call flow step numbering). 



Step 


Action 


CF ROAM REG 


1 


User B triggers registration to IIVIS B 


Step 1 


2 


User B is informed about successful registration 


Step 22 



4.4.1 .2 UC_01_R: SIP message flow for IMS registration with CF ROAM 



The expected call flow sequence is: 



step 


Direction 


IVIessage 


Comment 








U 
s 
e 
r 
B 


U 

E 
B 


1 
M 

s 

A 


1 

M 

s 

B 






1 














User B triggers registration to IMS B 


^ 


2 












REGISTER 


UE_B sends a REGISTER to IMS_A 


^ 


3 


REGISTER 


IMS_A forwards the REGISTER to IMS_B 


f 


4 


401 Unauthorized 


IMS B responds with 401 Unauthorized to 
IMS A 


V 


5 


401 Unauthorized 


IMS_A forwards the 401 Unauthorized to UE_B 




6 


REGISTER 


UE_B sends the same REGISTER containing 
authentication challenge response to IMS A 




7 


REGISTER 


IMS_A forwards the REGISTER to IMS B 




8 


200 OK 


IMS_B responds with 200 OK 


V 


9 


200 OK 


IMS_A forwards the 200 OK response to UE_B 




10 


SUBSCRIBE 


IMS_A sends a SUBSCRIBE to IMS_B 




11 


200 OK or 
202 Accepted 


IMS_B responds with a 200 OK or 202 
Accepted 




12 


NOTIFY 


IMS_B sends a NOTIFY to IMS_A, containing 
UE B's registration status 




13 


200 OK 


IMS_A responds to the NOTIFY with a 200 OK 


V 


14 


SUBSCRIBE 


UE_B sends a SUBSCRIBE (reg event 
package) to IMS A 




15 


SUBSCRIBE 


IMS A forwards the SUBSCRIBE request to 
IMS B 



















£75/ 



23 



ETSI TS 186 011-2 V2.3.1 (2010-04) 



Step 


Direction 


IVIessage 


Comment 








U 
s 
e 
r 
B 


U 

E 
B 


1 

lUI 
S 
A 


1 

M 
S 
B 






16 








^ 




200 OK or 
202 Accepted 


IMS_B responds to the SUBSCRIBE with a 200 
OK or 202 Accepted 




17 


200 OK or 
202 Accepted 


IMS_A forwards the 200 OK or 202 Accepted 
response to UE B 


f 


18 


NOTIFY 


IMS_B sends a NOTIFY to IMS_A, containing 
UE B's registration status 




19 


NOTIFY 


IMS_A forwards the NOTIFY to UE_B 




20 


200 OK 


UE_B responds to the NOTIFY with a 200 OK 




21 


200 OK 


IMS_A forwards the 200 OK to IMS_B 




22 




i 










User B is informed about successful registration 



4.4.2 User-initiated VoIP call setup and release 
4.4.2.1 Normal Call 



4.4.2.1.1 



Description 



UE_A places an IMS VoIP call to UE_B. Once the media path is established, the originating user releases the call. The 
call flow path and node configuration for this use case corresponds to CF_INT_CALL in case of interworking and 
CF_ROAM_CALL in case of roaming. 

The test sequence typically associated with this use case is as follows (CFW step numbers refer the call flow step 
numbering). 



4.4.2.1.2 



UC 02 I: SIP Call Flow "Normal Call" with CF INT CALL 



The test sequence and expected call flow sequence when user A calls user B in an interworking scenario is: 



Step 


Action 


CF INT CALL 


1 


User A calls User B 


Step1 


2 


User B is informed of incoming call of User A 


Steps 


3 


User A is informed that UE B is ringing 


Step 12 


4 


User B answers call 


Step 13 


5 


User A is informed that call has been answered 


Step 17 


6 


User B is informed that the call is established 


Step 21 


7A 


User A ends call 


Step 22A 


7B 


User B ends call 


Step 22B 


8A 


User B is informed that call has ended 


Step 26A 


SB 


User A is informed that call has ended 


Step 26B 


9A 


User A is informed that call has ended 


Step 30A 


9B 


User B is informed that call has ended 


Step SOB 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


u 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






1 




> 














User A calls User B 


2 
















INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired medias and codecs that 
UE A supports 


^ 


3 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




4 


INVITE 


IMS_A forwards INVITE to IMS_B 




5 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 




6 


INVITE 


IMS_B forwards INVITE to UE_B 


^ 


7 


100 Trying 


UE_B optionally responds with a 100 Trying 
provisional response 




8 












J 






User B is informed of incoming call of User A 


9 










^ 






180 Ringing 


UE_B responds to initial INVITE with 180 
Ringing to indicate that it has started alerting 




10 


180 Ringing 


IMS B forwards 180 Ringing response to 
IMS A 




11 


180 Ringing 


IMS A forwards the 1 80 Ringing response to 
UE A 




12 




i 














User A is informed that UE_B is ringing 


13 






User B answers call 


^ 


14 






^ 


^ 


^ 






200 OK 


UE_B responds to INVITE with 200 OK to 
indicate that the call has been answered 




15 


200 OK 


IMS_B forwards 200 OK response to IMS_A 




16 


200 OK 


IMS_A forwards the 200 OK response to UE_A 




17 




i 














User A is informed that call has been answered 


18 
















ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 




19 


ACK 


IMS_A forwards ACK to IMS_B 




20 


ACK 


IMS_B forwards ACK to UE_B 




21 












J 






User B is informed that the call is established 


22A 




> 














User A ends call 


23A 
















BYE 


UE_A releases the call with BYE 




24A 


BYE 


IMS_A forwards BYE to IMS_B 




25A 


BYE 


IMS_B forwards BYE to UE_B 




26A 


















User B is informed that call has ended 


^ 


27A 
















200 OK 


UE_B sends 200 OK for BYE 




28A 


200 OK 


IMS_B forwards 200 OK response to IMS_A 




29A 






^ 










200 OK 


IMS_A forwards the 200 OK response to UE_A 




30A 




i 














User A is informed that call has ended 


22B 


















User Bends call 


^ 


23B 






^ 


^ 


^ 






BYE 


UE_B releases the call with BYE 




24B 


BYE 


IMS_B forwards BYE to IMS_A 




258 


BYE 


IMS_A forwards BYE to UE_A 




26B 




<: 














User A is informed that call has ended 


27B 
















200 OK 


UE_A sends 200 OK for BYE 




288 


200 OK 


IMS_A forwards 200 OK response to IMS_B 




29B 


200 OK 


IMS_B forwards the 200 OK response to UE_B 




30d 






















— ^ 






User D IS informed that call has ended 
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4.4.2.1.3 



UC 02 R: SIP Call Flow "Normal Call" with CF ROAM CALL 



The expected call flow sequence when user A calls user B in a roaming scenario is: 



Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


1 
IVI 

s 

B 






1 




» 














User A calls User B 


2 
















INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired media and codecs that 
UE A supports 


^ 






3 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 








4 


INVITE 


IMS_A forwards INVITE to IMS_B 




5 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 


^ 


6 


INVITE 


IMS_B forwards the INVITE to IMS_A 




7 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




8 


INVITE 


IMS_A forwards the INVITE to UE_B 




9 


100 Trying 


UE_B optionally responds with a 100 Trying 
provisional response 




10 








i 










User B is informed of incoming call of User A 


11 






^ 










180 Ringing 


UE_B responds to initial INVITE with 180 
Ringing to indicate that it has started alerting 




12 


180 Ringing 


IMS A forwards 180 Ringing response to 
IMS B 




13 


180 Ringing 


IMS B forwards the 180 Ringing response to 
IMS A 




14 


180 Ringing 


IMS A forwards the 1 80 Ringing response to 
UE A 








15 




i 




> 










User A is informed that UE_B is ringing 


16 






User B answers call 


17 
















200 OK 


UE_B responds INVITE with 200 OK to indicate 
that the call has been answered 




18 


200 OK 


IMS_A forwards 200 OK response to IMS_B 




19 


200 OK 


IMS_B forwards the 200 OK response to IMS_A 




20 


200 OK 


IMS_A forwards the 200 OK response to UE_A 








21 


















User A is informed that call has been answered 


i 


22 
















ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 








23 
















ACK 


IMS_A forwards ACK to IMS_B 




24 


ACK 


IMS_B forwards ACK to IMS_A 




25 


ACK 


IMS_A forwards ACK to UE_B 




26 








d 










User B is informed that the call is established 


27A 




> 














User A ends call 


28A 
















BYE 


UE_A releases the call with BYE 






^ 


29A 


BYE 


IMS_A forwards BYE to IMS_B 


^ 


30A 


BYE 


IMS_B forwards BYE to IMS_A 




31A 


BYE 


IMS_A forwards BYE to UE_B 




32A 








i 










User B is informed that call has ended 


33A 






^ 










200 OK 


UE_B sends 200 OK for BYE 




34A 


200 OK 


IMS_A forwards 200 OK response to IMS_B 


^ 


35A 


200 OK 


IMS_B forwards the 200 OK response to IMS_A 




36A 


200 OK 


IMS_A forwards the 200 OK response to UE_A 








37A 




i 














User A is informed that call has ended 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


1 
IVI 

s 

B 






27B 








> 












User Bends call 


28B 






^ 










BYE 


UE_B releases the call with BYE 




29B 


BYE 


IMS_A forwards BYE to IMS_B 




308 


BYE 


IMS_B forwards BYE to IMS_A 




31B 


BYE 


IMS_A forwards BYE to UE_A 








32B 




d 














User A is informed that call has ended 


338 
















200 OK 


UE_A sends 200 OK for BYE 






^ 


34B 


200 OK 


IMS_A forwards 200 OK response to IMS_B 




35B 


200 OK 


IMS_B forwards the 200 OK response to IMS_A 




368 


200 OK 


IMS_A forwards the 200 OK response to UE_B 




Of a 












i — 
















User D IS informed that call has ended 



The test sequence and expected call flow sequence when user B calls user A in a roaming scenario is: 



Step 


Action 


CF ROAIM CALL 


1 


User B calls User A 


Slept 


2 


User A is informed of incoming call of User B 


Step 1 


3 


User B is informed that UE A is ringing 


Step 1 5 


4 


User A answers call 


Step 16 


5 


User B is informed that call has been answered 


Step 21 


6 


User A is informed that the call is established 


Step 26 


7A 


User A ends call 


Step 27A 


7B 


User B ends call 


Step 27B 


8A 


User B is informed that call has ended 


Step 32A 


8B 


User A is informed that call has ended 


Step 32B 


9A 


User A is informed that call has ended 


Step 37A 


9B 


User B is informed that call has ended 


Step 37B 



Step 


Direction 


Message 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


1 
IVI 

s 

B 






1 








» 










User B calls User A 


2 










V 


^. 




INVITE 


UE_B sends INVITE with the first SDP offer 
indicating all desired media and codecs that 
UE B supports 


^ 


3 


100 Trying 


ll\/IS_A responds with a 100 Trying provisional 
response 




4 


INVITE 


IMS_A forwards INVITE to IMS_B 




5 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 


^ 


6 


INVITE 


IMS_B forwards the INVITE to IMS_A 


^. 


7 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




8 


INVITE 


IMS_A forwards the INVITE to UE_A 






V 


9 


100 Trying 


UE_A optionally responds with a 100 Trying 
provisional response 








10 




d 














User A is informed of incoming call of User B 


11 












^. 




180 Ringing 


UE_A responds to initial INVITE with 180 
Ringing to indicate that it has started alerting 








12 


180 Ringing 


IMS A forwards 180 Ringing response to 
IMS B 


^ 


13 


180 Ringing 


IMS B forwards the 1 80 Ringing response to 
IMS A 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


1 
IVI 

s 

B 






14 










^ 






180 Ringing 


IMS A forwards the 1 80 Ringing response to 
UE B 




15 




» 




d 










User B is informed that UE_A is ringing 


16 






User A answers call 


17 
















200 OK 


UE_A responds INVITE with 200 OK to indicate 
that the call has been answered 






^ 


18 


200 OK 


IMS_A forwards 200 OK response to IMS_B 




19 


200 OK 


IMS_B forwards the 200 OK response to IMS_A 




20 


200 OK 


IMS_A forwards the 200 OK response to UE_B 




21 








i 










User B is informed that call has been answered 


22 






^ 










ACK 


UE B acknowledges the receipt of 200 OK for 
INVITE 




23 


ACK 


IMS_A forwards ACK to IMS_B 




24 


ACK 


IMS_B forwards ACK to IMS_A 




25 


ACK 


IMS_A forwards ACK to UE_A 








26 




i 














User A is informed that the call is established 


27A 




> 














User A ends call 


28A 
















BYE 


UE_A releases the call with BYE 








29A 


BYE 


IMS_A forwards BYE to IMS_B 


^ 


30A 


BYE 


IMS_B forwards BYE to IMS_A 




31A 


BYE 


IMS_A forwards BYE to UE_B 




32A 








i 










User B is informed that call has ended 


33A 
















200 OK 


UE_B sends 200 OK for BYE 




34A 


200 OK 


IMS_A forwards 200 OK response to IMS_B 


^ 


35A 


200 OK 


IMS_B forwards the 200 OK response to IMS_A 




36A 


200 OK 


IMS_A forwards the 200 OK response to UE_A 








37A 




i 














User A is informed that call has ended 


27B 








> 










User B ends call 


28B 






^ 










BYE 


UE_B releases the call with BYE 




29B 


BYE 


IMS_A forwards BYE to IMS_B 




308 


BYE 


IMS_B forwards BYE to IMS_A 




31B 


BYE 


IMS_A forwards BYE to UE_A 








32B 




i 














User A is informed that call has ended 


338 
















200 OK 


UE_A sends 200 OK for BYE 






^ 


34B 


200 OK 


IMS_A forwards 200 OK response to IMS_B 




35B 


200 OK 


IMS_B forwards the 200 OK response to IMS_A 




368 


200 OK 


IMS_A forwards the 200 OK response to UE_B 




O/D 












^ — 
















User D IS informed that call has ended 



4.4.3 User-initiated call hold and resume 

UE_A places an IMS VoIP call to UE_B. Once the media path is established: 

a) The originating user puts the call on hold, stopping the media stream. The originating user then resumes the 
call. 

b) The terminating user puts the call on hold, stopping the media stream. The terminating user then resumes the 
call. 

The call flow path and node configuration for this use case corresponds to CF_INT_CALL in case of interworking and 
CF_ROAM_CALL in case of roaming. 
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Depending on the UE this feature may be implemented either using relNVITE or UPDATE where UPDATE is only an 
optional feature for the UE. However, an IMS shall be able to process UPDATE requests as they may be received when 
inter working with a PSTN. 



4.4.3.1 



User-initiated call hold and resume using relNVITE 



4.4.3.1.1 



Description 



The test sequence typically associated with this use case is as follows (CFW step numbers refer the call flow step 
numbering). 



Step 


Action 


CF INT CALL 


CF ROAM CALL 


1 


User A calls User 8 


1 


1 


2 


User B is informed of incoming call of User A 


8 


10 


3 


User A is informed that UE 8 is ringing 


12 


15 


4 


User B answers call 


13 


16 


5 


User A is informed that call has been answered 


17 


21 


6 


User B is presented that call is established 


27 


26 


7A 


User A puts call on hold 


22A 


27A 


7B 


User 8 puts call on hold 


228 


278 


8A 


User 8 is informed that call on hold 


29A 


36A 


8B 


User A is informed that call on hold 


298 


368 


9A 


User A resumes call 


36A 


45A 


9B 


User 8 resumes call 


368 


458 


10A 


User 8 is informed that call is resumed 


43A 


54A 


108 


User A is informed that call is resumed 


438 


54A 


11A 


User A is informed that call is resumed 


47A 


59A 


118 


User 8 is informed that call is resumed 


478 


598 


12 


User A ends call 


51 


64 


13 


User 8 is informed that call has ended 


55 


69 


14 


User A is informed that call has ended 


59 


73 



4.4.3.1 .2 UC_03_I: SIP Call Flow "call hold and resume" using relNVITE with 

CF_INT_CALL 

The expected call flow sequence is: 



Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

lUI 
S 
A 


1 
lUI 

s 

B 


U 

E 
B 


U 
s 
e 
r 
B 






1 




» 














User A calls User 8 


2 






V 










INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired media and codecs that 
UE A supports 


^ 


3 


100 Trying 


ll\/IS_A responds with a 100 Trying provisional 
response 




4 


INVITE 


IMS A forwards INVITE to IMS 8 


^ 


5 


100 Trying 


IMS_8 responds with a 100 Trying provisional 
response 




6 


INVITE 


IMS 8 forwards INVITE to UE 8 




7 


100 Trying 


UE_8 optionally responds with a 100 Trying 
provisional response 




8 












^ 






User 8 is informed of incoming call of User A 


9 






^ 










180 Ringing 


UE_8 responds to initial INVITE with 180 
Ringing to indicate that it has started alerting 




10 


180 Ringing 


IMS 8 forwards 180 Ringing response to 
IMS A 




11 


180 Ringing 


IMS A forwards the 1 80 Ringing response to 
UE A 




12 




i 














User A is informed that UE 8 is ringing 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


u 

E 
B 


u 

s 
e 
r 
B 






13 


















User B answers call 


i 


14 






^ 




^ 






200 OK 


UE_B responds to INVITE with 200 OK to 
indicate that the call has been answered 




15 


200 OK 


IMS B forwards 200 OK response to IMS A 




16 


200 OK 


IMS A forwards the 200 OK response to UE A 




17 




i 














User A is informed that call has been answered 


18 
















ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 




19 


ACK 


IMS A forwards ACK to IMS B 




20 


ACK 


IMS B forwards ACK to UE B 




21 












J 






User B is presented that call is in progress 


22A 




> 














User A puts call on hold 


23A 
















INVITE 


UE_A sends relNVITE message indicating 
media attribute "sendonly" (Call Hold) 


^ 


24A 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




25A 


INVITE 


IMS A forwards INVITE to IMS B 


^ 


26A 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 




27A 


INVITE 


IMS B forwards INVITE to UE B 




28A 


100 Trying 


UE_B optionally responds with a 100 Trying 
provisional response 




29A 












^ 






User B is informed that call is on hold 


30A 
















200 OK 


UE_B responds to relNVITE with 200 OK 
indicating media attribute "recvonly" 




31A 


200 OK 


IMS B forwards 200 OK response to IMS A 




32A 


200 OK 


IMS A forwards the 200 OK response to UE A 




33A 


ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 




34A 


ACK 


IMS A forwards ACK to IMS B 




35A 


ACK 


IMS B forwards ACK to UE B 




36A 
37A 




> 












INVITE 


User A resumes call 

UE_A sends relNVITE message indicating 

media attribute "sendrecv" (Call Resume) 


^ 


38A 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




39A 


INVITE 


IMS A forwards INVITE to IMS B 




40A 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 




41A 


INVITE 


IMS B forwards INVITE to UE B 




42A 


100 Trying 


UE_B optionally responds with a 100 Trying 
provisional response 




43A 












J 






User B is informed that call is resumed 


44A 






^ 




^ 






200 OK 


UE_B responds to relNVITE with 200 OK 
indicating media attribute "recvonly" 




45A 


200 OK 


IMS B forwards 200 OK response to IMS A 




46A 


200 OK 


IMS A forwards the 200 OK response to UE A 




47A 




i 














User A is informed that call is resumed 


48A 
















ACK 


UE A acknowledges the receipt of 200 OK for 
relNVITE 




49A 


ACK 


IMS A forwards ACK to IMS B 




50A 


ACK 


IMS B forwards ACK to UE B 




22B 


















User B puts call on hold 


i 


23B 
















INVITE 


UE_B sends relNVITE message indicating 
media attribute "sendonly" (Call Hold) 




24B 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 




25B 








^ 








INVITE 


IMS B forwards INVITE to IMS A 




26B 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




y 



£75/ 



30 



ETSI TS 186 011-2 V2.3.1 (2010-04) 



Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 

B 


u 

E 
B 


U 
s 
e 
r 
B 






27B 
















INVITE 


IMS A forwards INVITE to UE A 




28B 


100 Trying 


UE_A optionally responds with a 100 Trying 
provisional response 




29B 




i 














User A is informed that call is on hold 


308 
















200 OK 


UE_A responds to relNVITE with 200 OK 
indicating media attribute "recvonly" 


^ 


31 B 


200 OK 


IMS A forwards 200 OK response to IMS B 




32B 


200 OK 


IMS B forwards the 200 OK response to UE B 


^ 


33B 


ACK 


UE B acknowledges the receipt of 200 OK for 
relNVITE 




34B 


ACK 


IMS B forwards ACK to IMS A 




35B 


ACK 


IMS A forwards ACK to UE A 




36B 












d 






User B resumes call 


37B 










^ 






INVITE 


UE_B sends relNVITE message indicating 
media attribute "sendrecv" (Call Resume) 




38B 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 




39B 


INVITE 


IMS B forwards INVITE to IMS A 




40B 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




41B 


INVITE 


IMS A forwards INVITE to UE A 




42B 


100 Trying 


UE_A optionally responds with a 100 Trying 
provisional response 




43B 




i 














User A is informed that call is resumed 


44B 
















200 OK 


UE_A responds to relNVITE with 200 OK 
indicating media attribute "sendrecv" 




45B 


200 OK 


IMS A forwards 200 OK response to IMS B 




46B 


200 OK 


IMS B forwards the 200 OK response to UE B 




47B 












^ 






User B is informed that call is resumed 


48B 








^ 








ACK 


UE B acknowledges the receipt of 200 OK for 
relNVITE 




49B 


ACK 


IMS B forwards ACK to IMS A 




SOB 


ACK 


IMS A forwards ACK to UE A 




51 




> 














User A ends call 


52 
















BYE 


UE A releases the call with BYE 




53 


BYE 


IMS A forwards BYE to IMS B 




54 


BYE 


IMS B forwards BYE to UE B 




55 












^ 






User B is informed that call has ended 


56 








^ 








200 OK 


UE B sends 200 OK for BYE 




57 


200 OK 


IMS B forwards 200 OK response to IMS A 




58 


200 OK 


IMS A forwards the 200 OK response to UE A 




59 




i — 
























User A is informed that call has ended 



4.4.3.1 .3 UC_03_R: SIP Call Flow "call hold and resume" using relNVITE with 

CF_ROAM_CALL 

The expected call flow sequence is: 



Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


1 
IVI 

s 

B 






1 




» 














User A calls User B 


2 
















INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired media and codecs that 
UE A supports 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


u 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


1 

IVI 

s 

B 






3 
















100 Trying 


IMS_A responds with a 100 Trying provisional 
response 








4 


INVITE 


IMS A forwards INVITE to IMS B 




5 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 




6 


INVITE 


IMS B forwards INVITE to IMS A 




7 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




8 


INVITE 


IMS A forwards INVITE to UE B 




9 


100 Trying 


UE_B optionally responds with a 100 Trying 
provisional response 




10 








i 










User B is informed of incoming call of User A 


11 






^ 










180 Ringing 


UE_B responds to initial INVITE with 180 
Ringing to indicate that it has started alerting 




12 


180 Ringing 


IMS A forwards 180 Ringing response to 
IMS B 


^ 


13 


180 Ringing 


IMS B forwards the 180 Ringing response to 
IMS A 




14 


180 Ringing 


IMS A forwards the 1 80 Ringing response to 
UE A 








15 




i 




» 










User A is informed that UE B is ringing 


16 






User B answers call 


17 






^ 










200 OK 


UE_B responds to INVITE with 200 OK to 
indicate that the call has been answered 




18 


200 OK 


IMS A forwards 200 OK response to IMS B 




19 


200 OK 


IMS B forwards 200 OK response to IMS A 




20 


200 OK 


IMS A forwards the 200 OK response to UE A 








21 


















User A is informed that call has been answered 


i 


22 
















ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 








23 


ACK 


IMS A forwards ACK to IMS B 


^ 


24 


ACK 


IMS B forwards ACK to IMS A 




25 


ACK 


IMS A forwards ACK to UE B 




26 








i 










User B is presented that call is established 


27A 




> 














User A puts call on hold 


28A 
















INVITE 


UE_A sends relNVITE message indicating 
media attribute "sendonly" (Call Hold) 








29A 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 








30A 


INVITE 


IMS A forwards INVITE to IMS B 




31A 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 




32A 


INVITE 


IMS B forwards INVITE to IMS A 




33A 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




34A 


INVITE 


IMS A forwards INVITE to UE B 




35A 


100 Trying 


UE_B optionally responds with a 100 Trying 
provisional response 




36A 








i 










User B is informed that call is on hold 


37A 






^ 










200 OK 


UE_B responds to relNVITE with 200 OK 
indicating media attribute "recvonly" 




38A 


200 OK 


IMS A forwards 200 OK response to IMS B 




39A 


200 OK 


IMS B forwards 200 OK response to IMS A 




40A 


200 OK 


IMS A forwards the 200 OK response to UE A 








41A 


ACK 


UE A acknowledges the receipt of 200 OK for 
relNVITE 






^ 


42A 


ACK 


IMS A forwards ACK to IMS B 




43A 


ACK 


IMS B forwards ACK to IMS A 




44A 
45A 


ACK 


IMS A forwards ACK to UE B 
User A resumes call 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


1 

IVI 

s 

B 






46A 
















INVITE 


UE_A sends relNVITE message indicating 
media attribute "sendrecv" (Call Resume) 








47A 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 








48A 


INVITE 


IMS A forwards INVITE to IMS B 




49A 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 


f 


50A 


INVITE 


IMS B forwards INVITE to IMS A 




51A 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




52A 


INVITE 


IMS A forwards INVITE to UE B 




53A 


100 Trying 


UE_B optionally responds with a 100 Trying 
provisional response 




54A 








i 










User B is informed that call is resumed 


55A 
















200 OK 


UE_B responds to relNVITE with 200 OK 
indicating media attribute "sendrecv" 




56A 


200 OK 


IMS A forwards 200 OK response to IMS B 




57A 


200 OK 


IMS B forwards 200 OK response to IMS A 




58A 


200 OK 


IMS A forwards the 200 OK response to UE A 








59A 




« 














User A is informed that call is resumed 


60A 
















ACK 


UE A acknowledges the receipt of 200 OK for 
relNVITE 








61A 


ACK 


IMS A forwards ACK to IMS B 




62A 


ACK 


IMS B forwards ACK to IMS A 




63A 










^ 






ACK 


IMS A forwards ACK to UE B 




27B 








> 










User B puts call on hold 


28B 






^ 










INVITE 


UE_B sends relNVITE message indicating 
media attribute "sendonly" (Call Hold) 


^ 


290 
B 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




SOB 


INVITE 


IMS A forwards INVITE to IMS B 


f 


31B 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 




32B 


INVITE 


IMS B forwards INVITE to IMS A 




33B 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




34B 


INVITE 


IMS A forwards INVITE to UE A 








35B 


100 Trying 


UE_A optionally responds with a 100 Trying 
provisional response 








36B 




« 














User A is informed that call is on hold 


37B 
















200 OK 


UE_A responds to relNVITE with 200 OK 
indicating media attribute "recvonly" 






^ 


38B 


200 OK 


IMS A forwards 200 OK response to IMS B 




39B 


200 OK 


IMS B forwards 200 OK response to IMS A 




40B 


200 OK 


IMS A forwards the 200 OK response to UE B 




41B 






^ 










ACK 


UE B acknowledges the receipt of 200 OK for 
relNVITE 




42B 


ACK 


IMS A forwards ACK to IMS B 




43B 


ACK 


IMS B forwards ACK to IMS B 




44B 


ACK 


IMS A forwards ACK to UE A 








46B 








? 








INVITE 


UE_B sends relNVITE message indicating 
media attribute "sendrecv" (Call Resume) 


^ 


47B 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




48B 


INVITE 


IMS A forwards INVITE to IMS B 


f 


49B 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 


f 


SOB 


INVITE 


IMS B forwards INVITE to IMS A 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


1 
IVI 

s 

B 






51 B 






^ 










100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




52B 


INVITE 


IMS A forwards INVITE to UE A 








538 


100 Trying 


UE_A optionally responds with a 100 Trying 
provisional response 








54B 




i 














User A is informed that call is resumed 


55B 
















200 OK 


UE_A responds to relNVITE with 200 OK 
indicating media attribute "sendrecv" 








568 


200 OK 


IMS A forwards 200 OK response to IMS B 


^ 


57B 


200 OK 


IMS B forwards 200 OK response to IMS A 




58B 


200 OK 


IMS A forwards the 200 OK response to UE B 




59B 








i 










User B is informed that call is resumed 


60B 






^ 










ACK 


UE B acknowledges the receipt of 200 OK for 
relNVITE 




61B 


ACK 


IMS A forwards ACK to IMS B 




62B 


ACK 


IMS B forwards ACK to IMS A 




63B 


ACK 


IMS A forwards ACK to UE A 








64 




> 














User A ends call 


65 
















BYE 


UE A releases the call with BYE 








66 


BYE 


IMS A forwards BYE to IMS B 


^ 


67 


BYE 


IMS B forwards BYE to IMS B 




68 
















BYE 


IMS B forwards BYE to UE B 




69 








i 










User B is informed that call has ended 


70 
















200 OK 


UE B sends 200 OK for BYE 




71 


200 OK 


IMS A forwards 200 OK response to IMS B 


^ 


72 


200 OK 


IMS B forwards 200 OK response to IMS A 




73 


200 OK 


IMS A forwards the 200 OK response to UE A 








74 




i 














User A is informed that call has ended 



4.4.3.2 



User-initiated call hold and resume using UPDATE 



4.4.3.2.1 



Description 



The test sequence typically associated with this use case is as follows (CFW step numbers refer the call flow step 
numbering). 



step 


Action 


CF INT CALL 


CF ROAM CALL 


1 


User A calls User B 


1 


1 


2 


User B is informed of incoming call of User A 


8 


10 


3 


User A is informed that UE B is ringing 


12 


15 


4 


User B answers call 


13 


16 


5 


User A is informed that call has been answered 


17 


21 


6 


User B is informed that call is established 


21 


26 


7A 


User A puts call on hold 


22A 


27A 


7B 


User B puts call on hold 


22B 


27B 


8A 


User B is informed that call on hold 


26A 


32A 


8B 


User A is informed that call on hold 


26B 


32B 


9A 


User A resumes call 


30A 


37A 


9B 


User B resumes call 


30B 


37B 


10A 


User B is informed that call is resumed 


34A 


42A 


10B 


User A is informed that call is resumed 


34B 


42B 


11A 


User A is informed that call is resumed 


38A 


47A 


11 


User A is informed that call is resumed 


38B 


47B 


12 


User A ends call 


39 


48 


13 


User B is informed that call has ended 


43 


53 


14 


User A is informed that call has ended 


47 


58 
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4.4.3.2.2 UC_04_I: SIP Call Flow "call hold and resume" using UPDATE with 

CF_INT_CALL 

The expected call flow sequence is: 



Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 

B 


u 

E 
B 


u 

s 
e 
r 
B 






1 




> 














User A calls User B 


2 
















INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired medias and codecs that 
UE A supports 


^ 


3 


100 Trying 


IMS_AW responds with a 100 Trying provisional 
response 




4 


INVITE 


IMS A forwards INVITE to IMS B 




5 








^ 








100 Trying 


IMS_B responds with a 100 Trying provisional 
response 




6 


INVITE 


IMS B forwards INVITE to UE B 




7 


100 Trying 


UE_B optionally responds with a 100 Trying 
provisional response 




8 












^ 






User B is informed of incoming call of User A 


9 
















180 Ringing 


UE_B responds to initial INVITE with 180 
Ringing to indicate that it has started alerting 




10 


180 Ringing 


IMS B forwards 180 Ringing response to 
IMS A 




11 


180 Ringing 


IMS A forwards the 1 80 Ringing response to 
UE A 




12 




d 














User A is informed that UE B is ringing 


13 






User B answers call 


i 


14 










^ 






200 OK 


UE_B responds to INVITE with 200 OK to 
indicate that the call has been answered 




15 


200 OK 


IMS B forwards 200 OK response to IMS A 




16 






^ 










200 OK 


IMS_A forwards the 200 OK response to UE_A 




17 




i 














User A is informed that call has been answered 


18 
















ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 




19 


ACK 


IMS A forwards ACK to IMS B 




20 


ACK 


IMS B forwards ACK to UE B 




21 












J 






User B is informed that call is established 


22A 




> 














User A puts call on hold 


23A 
















UPDATE 


UE_A sends UPDATE message indicating 
media attribute "sendonly" (Call Hold) 




24A 


UPDATE 


IMS A forwards UPDATE to IMS B 




25A 


UPDATE 


IMS B forwards UPDATE to UE B 




26A 












^ 






User B is informed that call is on hold 


27A 








^ 








200 OK 


UE_B responds to UPDATE with 200 OK 
indicating media attribute "recvonly" 




28A 


200 OK 


IMS B forwards 200 OK response to IMS A 




29A 


200 OK 


IMS A forwards the 200 OK response to UE A 




31A 




? 












UPDATE 


UE_A sends UPDATE message indicating 
media attribute "sendrecv" (Call Resume) 




32A 


UPDATE 


IMS A forwards UPDATE to IMS B 




33A 


UPDATE 


IMS B forwards UPDATE to UE B 




34A 












^ 






User B is informed that call is resumed 


35A 








^ 








200 OK 


UE_B responds to UPDATE with 200 OK 
indicating media attribute "sendrecv" 




36A 


200 OK 


IMS B forwards 200 OK response to IMS A 




37A 


200 OK 


IMS A forwards the 200 OK response to UE A 




38A 




i 














User A is informed that call is resumed 


22B 


















User B puts call on hold 


i 


23B 
















UPDATE 


UE_B sends UPDATE message indicating 
media attribute "sendonly" (Call Hold) 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






24B 




^ 












UPDATE 


IMS B forwards UPDATE to IMS A 




25B 


UPDATE 


IMS A forwards UPDATE to UE A 




26B 




User A Is informed that call on hold 




27B 


200 OK 


UE_A responds to UPDATE with 200 OK 
indicating media attribute "recvonly" 




28B 


200 OK 


IMS A forwards 200 OK response to IMS B 




29B 


200 OK 


IMS B forwards the 200 OK response to UE B 




SOB 












d 






User B resumes call 


31B 
















UPDATE 


UE_B sends UPDATE message indicating 
media attribute "sendrecv" (Call Resume) 




32B 


UPDATE 


IMS B forwards UPDATE to IMS A 




33B 


UPDATE 


IMS A forwards UPDATE to UE A 




34B 




« 














User A is informed that call is resumed 


35B 
















200 OK 


UE_A responds to UPDATE with 200 OK 
indicating media attribute "sendrecv" 




36B 


200 OK 


IMS A forwards 200 OK response to IMS B 




37B 


200 OK 


IMS B forwards the 200 OK response to UE B 




38B 












^ 






User B is informed that call is resumed 


39 




» 














User A ends call 


40 
















BYE 


UE A releases the call with BYE 




41 


BYE 


IMS A forwards BYE to IMS B 




42 


BYE 


IMS B forwards BYE to UE B 




43 












J 






User B is informed that call has ended 


44 
















200 OK 


UE B sends 200 OK for BYE 




45 






^ 










200 OK 


IMS B forwards 200 OK response to IMS A 




46 


200 OK 


IMS_A forwards the 200 OK response to UE_A 




47 




























User A is informed that call has ended 



4.4.3.2.3 UC_04_R: SIP Call Flow "call hold and resume" using UPDATE with 

CF_ROAM_CALL 

The expected call flow sequence is: 



Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


1 
IVI 

s 

B 






1 




> 














User A calls User B 


2 










V 






INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired media and codecs that 
UE A supports 


f 






3 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 






^ 


4 


INVITE 


IMS A forwards INVITE to IMS B 


^ 


5 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 


^ 


6 


INVITE 


IMS B forwards the INVITE to IMS A 




7 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




8 


INVITE 


IMS A forwards the INVITE to UE B 




9 


100 Trying 


UE_B optionally responds with a 100 Trying 
provisional response 




10 








« 










User B is informed of incoming call of User A 


11 










V 






180 Ringing 


UE_B responds to initial INVITE with 180 
Ringing to indicate that it has started alerting 




/ 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


u 

E 
B 


1 

M 
S 
A 


1 
IVI 

s 

B 






12 






^ 










180 Ringing 


IIVIS A forwards 180 Ringing response to 
IMS B 




13 


180 Ringing 


IMS B forwards the 1 80 Ringing response to 
IMS A 




14 


180 Ringing 


IMS A forwards the 1 80 Ringing response to 
UE A 








15 




i 














User A is informed that UE B is ringing 


16 








> 










User B answers call 


17 






^ 










200 OK 


UE_B responds INVITE with 200 OK to indicate 
that the call has been answered 




18 


200 OK 


IMS A forwards 200 OK response to IMS B 


^ 


19 


200 OK 


IMS B forwards the 200 OK response to IMS A 




20 


200 OK 


IMS_A forwards the 200 OK response to UE_A 








21 




i 














User A is informed that call has been answered 


22 
















ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 








23 


ACK 


IMS A forwards ACK to IMS B 




24 


ACK 


IMS B forwards ACK to IMS A 




25 


ACK 


IMS A forwards ACK to UE B 




26 








d 










User B is informed that the call is established 


27A 




> 














User A puts call on hold 


28A 
















UPDATE 


UE_A sends UPDATE message indicating 
media attribute "sendonly" (Call Hold) 








29A 
















UPDATE 


IMS A forwards UPDATE to IMS B 


^ 


30A 


UPDATE 


IMS B forwards UPDATE to IMS A 




31A 


UPDATE 


IMS A forwards UPDATE to UE B 




32A 








i 










User B is informed that call is on hold 


33A 
















200 OK 


UE_B responds to UPDATE with 200 OK 
indicating media attribute "recvonly" 




34A 


200 OK 


IMS A forwards 200 OK response to IMS B 




35A 


200 OK 


IMS B forwards 200 OK response to IMS A 




36A 


200 OK 


IMS A forwards the 200 OK response to UE A 








38A 
















UPDATE 


UE_A sends UPDATE message indicating 
media attribute "sendrecv" (Call Resume) 






^ 


39A 


UPDATE 


IMS A forwards UPDATE to IMS B 




40A 


UPDATE 


IMS B forwards UPDATE to IMS A 




41A 


UPDATE 


IMS A forwards UPDATE to UE B 




42A 








i 










User B is informed that call is resumed 


43A 
















200 OK 


UE_B responds to UPDATE with 200 OK 
indicating media attribute "sendrecv" 




44A 


200 OK 


IMS A forwards 200 OK response to IMS B 


^ 


45A 


200 OK 


IMS B forwards 200 OK response to IMS A 




46A 


200 OK 


IMS A forwards the 200 OK response to UE A 








47A 




i 














User A is informed that call is resumed 


27B 








> 










User B puts call on hold 


28B 






^ 










UPDATE 


UE_B sends UPDATE message indicating 
media attribute "sendonly" (Call Hold) 




29B 


UPDATE 


IMS A forwards UPDATE to IMS B 


^ 


308 


UPDATE 


IMS B forwards UPDATE to IMS A 




31B 


UPDATE 


IMS A forwards UPDATE to UE A 








32B 




i 














User A is informed that call on hold 


338 
















200 OK 


UE_A responds to UPDATE with 200 OK 
indicating media attribute "recvonly" 








34B 


200 OK 


IMS A forwards 200 OK response to IMS B 


^ 


35B 


200 OK 


IMS B forwards 200 OK response to IMS A 




36B 


200 OK 


IMS A forwards the 200 OK response to UE B 




38B 








7 


N 






UPDATE 


UE_B sends UPDATE message indicating 
media attribute "sendrecv" (Call Resume) 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


1 
IVI 

s 

B 






39B 
















UPDATE 


IMS A forwards UPDATE to IMS B 




40B 


UPDATE 


IMS B forwards UPDATE to IMS A 




41 B 






^ 










UPDATE 


IMS A forwards UPDATE to UE A 








42B 




i 














User A is informed that call is resumed 


43B 
















200 OK 


UE_A responds to UPDATE with 200 OK 
indicating media attribute "sendrecv" 








44B 


200 OK 


IMS A forwards 200 OK response to IMS B 


^ 


45B 


200 OK 


IMS B forwards 200 OK to IMS A 




46B 


200 OK 


IMS A forwards the 200 OK response to UE B 




47B 








i 










User B is informed that call is resumed 


48 




5> 














User A ends call 


49 
















BYE 


UE A releases the call with BYE 








50 


BYE 


IMS A forwards BYE to IMS B 




51 


BYE 


IMS B forwards BYE to IMS A 




52 


BYE 


IMS A forwards BYE to UE B 




53 








d 










User B is informed that call has ended 


54 
















200 OK 


UE B sends 200 OK for BYE 




55 


200 OK 


IMS A forwards 200 OK response to IMS B 




56 
















200 OK 


IMS B forwards the 200 OK response to IMS A 




57 


200 OK 


IMS A forwards the 200 OK response to UE A 








58 




























User A is informed that call has ended 



4.4.4 IMS message exchange between UEs in different networl^s 
4.4.4.1 Description 

The UE_A sends a MESSAGE to UE_B located in a different network. 

The test sequence typically associated with this use case when an established session is released is as follows (CFW 
step numbers refer the call flow step numbering). 



Step 


Action 


CF INT CALL 


CF ROAM CALL 


1 


User A sends an instant message 


Stepi 


Slept 


2 


User B is informed about the instant message 


Step 5 


Steps 


3 


Optional: User A is presented a delivery report 


Step 9 


Step 1 1 



4.4.4.2 



UC_05_I: SIP Call flow for IMS Message Exchange with CF_INT_CALL 



The expected call flow sequence is: 



Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






1 




> 














User A sends an instant message to user B 


2 
















MESSAGE 


UE A sends MESSAGE to IMS A 




3 


MESSAGE 


IMS A sends MESSAGE to IMS B 




4 


MESSAGE 


IMS B sends MESSAGE to UE B 




5 












^ 






User B is informed about the instant message 


6 






^ 




^ 






200 OK 


UE B sends 200 OK to IMS B 




7 


200 OK 


IMS B sends 200 OK to IMS A 




8 


200 OK 


IMS A sends 200 OK to UE A 




9 


















Optional: User A is presented a delivery report 


i 
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4.4.4.3 



UC_05_R: SIP Call Flow for IMS Message Exchange with CF_ROAM_CALL 



The expected call flow sequence is: 



Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


1 
IVI 

s 

B 






1 




> 














User A sends an instant message to user B 


2 












>. 




MESSAGE 


UE A sends MESSAGE to IMS A 








3 


MESSAGE 


IMS A forwards MESSAGE to IMS B 




4 


MESSAGE 


IMS B forwards MESSAGE to IMSA 




5 


MESSAGE 


IMS A forwards MESSAGE to UE B 




6 








d 










User B is informed about the instant message 


7 












>. 




200 OK 


UE B responds with 200 OK to IMS A 




8 


200 OK 


IMS A forwards 200 OK to IMS B 




9 


200 OK 


IMS B forwards 200 OK to IMS A 




10 


200 OK 


IMS A forwards 200 OK to UE A 








11 




d 














Optional: User A is presented a delivery report 



4.4.5 Supplementary Service Anonymous Communication Rejection 
(ACR) 



4.4.5.1 



Description 



UE_A makes an IMS VoIP call to UE_B. UE_A is subscribed to OIR service in permanent mode or default 
presentation restricted temporary mode, UE_B is subscribed to ACR supplementary service. The call flow path and 
node configuration for this use case corresponds to CF_INT_AS when UE_B is in home network and to 
CF_ROAM_AS when UE_B is roaming in IMS_A. 

The test sequence typically associated with this use case when is as follows (CFW step numbers refer the call flow step 
numbering): 



Step 


Action 


CF INT AS 


1 


User A calls User B 


Stepi 


2 


User A is informed that call has been rejected due to ACR 


Step 1 7 




Step 


Action 


CF ROAIM AS 


1 


User B calls User A 


Stepi 


2 


User B is informed that call has been rejected due to ACR 


Step 20 
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4.4.5.2 



UC_06_I: SIP message flow for SS ACR with CF_INT_AS 



The expected call flow sequence is: 



Step 


Direction 


IVIessage 


Comment 


-1 


U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 

1 


1 

M 
S 
A 


A 
S 
A 

1 


1 
IVI 

s 

B 


A 
S 
B 




1 Iqpt a rallc: 1 Icpr R 


2 










V 










INVITE 


UE_A sends INVITE with the first SDP 
offer indicating all desired media and 
codecs that UE A supports 


f 






3 


100 Trying 


IMS_A responds with a 100 Trying 
provisional response 






























INVITE triggers the OIR IPC in IMS A 


4 




















INVITE 


IMS A forwards the INVITE to IMS A AS 




5 


100 Trying 


IMS_A AS optionally responds with a 100 
Trying provisional response 


^ 


6 


INVITE 


IMS_A AS returns modified INVITE 
including Privacy header (value "id" or 
"header") to IMS A 




7 


100 Trying 


IMS_A responds with a 100 Trying 
provisional response 




8 


INVITE 


IMS A forwards INVITE to IMS B 


^ 


9 


100 Trying 


IMS_B responds with a 100 Trying 
provisional response 


























INVITE triggers the ACR IPC in IMS B 


10 














^ 






INVITE 


IMS B forwards the INVITE to IMS B AS 




11 


100 Trying 


AS optionally responds with a 100 Trying 
provisional response 




12 


433 

Anonymity 

Disallowed 


IMS_B AS responds with 433 Anonymity 
Disallowed to IMS_B 




13 


433 

Anonymity 

Disallowed 


IMS_B forwards the 433 Anonymity 
Disallowed to IMS_A 




14 


433 

Anonymity 

Disallowed 


IMS A forwards the 433 Anonymity 
Disallowed to IMS_A AS 




15 


433 

Anonymity 

Disallowed 


IMS_A AS forwards, possibly modified, 
433 Anonymity Disallowed to IMS_A 




16 


433 

Anonymity 

Disallowed 


IMS_A forwards the 433 Anonymity 
Disallowed to UE_A 








17 






















User A is informed that the call has been 
rejected due to ACR 


i 




18 














■>. 






ACK 


UE A sends ACK to IMS A 








19 


ACK 


IMS A forwards the ACK to IMS A AS 




20 


ACK 


IMS A AS forwards, possibly modified, 
ACK to IMS A 




21 


ACK 


IMS A forwards ACK to IMS B 




22 


ACK 


IMS B forwards ACK to IMS B AS 
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4.4.5.3 



UC_06_R: SIP message flow for SS ACR with CF_ROAM_AS 



The expected call flow sequence is: 



Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


A 
S 
A 


1 
IVI 

s 

B 


A 
S 
B 






1 








> 














User B calls User A 


2 










V 










INVITE 


UE_A sends INVITE with the first SDP 
offer indicating all desired media and 
codecs that UE A supports 


f 


3 


100 Trying 


IMS_A responds with a 100 Trying 
provisional response 




4 


INVITE 


IMS A sends INVITE to IMS B 


^ 




5 


100 Trying 


IMS_B responds with a 100 Trying 
provisional response 




























INVITE triggers the OIR IPC in IMS A 


6 




















INVITE 


IMS B forwards the INVITE to IMS B AS 


^ 


7 


100 Trying 


IMS_B AS optionally responds with a 100 
Trying provisional response 


^ 


8 


INVITE 


IMS_B AS returns modified INVITE 
including Privacy header (value "id" or 
"header") to IMS B 




9 


100 Trying 


IMS_B responds with a 100 Trying 
provisional response 




10 


INVITE 


IMS B forwards INVITE to IMS A 






11 


100 Trying 


IMS_A responds with a 100 Trying 
provisional response 




























INVITE triggers the ACR IPC in IMS B 


12 














■>. 






INVITE 


IMS A forwards the INVITE to IMS A AS 


^ 


13 


100 Trying 


AS optionally responds with a 100 Trying 
provisional response 


^ 


14 


433 

Anonymity 

Disallowed 


IMS_A AS responds with 433 Anonymity 
Disallowed to IMS_A 




15 


433 

Anonymity 

Disallowed 


IMS_A forwards the 433 Anonymity 
Disallowed to IMS_B 


^ 




16 


433 

Anonymity 

Disallowed 


IMS B forwards the 433 Anonymity 
Disallowed to IMS_B AS 




17 


433 

Anonymity 

Disallowed 


IMS_B AS forwards, possibly modified, 
433 Anonymity Disallowed to IMS_B 




18 


433 

Anonymity 

Disallowed 


IMS_B forwards the 433 Anonymity 
Disallowed to IMS_A 






19 


433 

Anonymity 

Disallowed 


IMS_A forwards the 433 Anonymity 
Disallowed to UE_B 




20 






















User B Is informed that the call has been 
rejected due to ACR 


i 




21 










V 






»- 




ACK 


UE B sends ACK to IMS A 




22 


ACK 


IMS A sends ACK to IMS B 


^ 




23 


ACK 


IMS B forwards the ACK to IMS B AS 




24 


ACK 


IMS B AS forwards, possibly modified, 
ACK to IMS B 




25 


ACK 


IMS B forwards ACK to IMS A 






26 


ACK 


IMS A forwards ACK to IMS A AS 
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4.4.6 Supplementary Service Outgoing Communication Barring (OCB) 



4.4.6.1 



Description 



UE_B places an IMS VoIP call to UE_A. UE_B is subscribed to OCB service and based on the UE_B identity the OCB 
service is invoked. The call flow path and node configuration for this use case corresponds to CF_INT_AS when UE_B 
is in home network and to CF_ROAM_AS when UE_B is roaming in IMS_A. 

The test sequence typically associated with this use case is as follows (CFW step numbers refer the call flow step 
numbering). 



Step 


Action 


CF INT AS 


CF ROAM AS 


1 


User B calls User A 


Step1 


Step1 


2 


User B is informed that call was declined 


Steps 


Step 1 1 



4.4.6.2 



UC_07_I: SIP message flow for SS OCB with CF_INT_AS 



The expected call flow sequence is: 



Step 


Direction 


Message 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


1 

M 
S 
B 


A 
S 
B 






1 




















User B calls User A 


^ 


2 


















INVITE 


UE_B sends INVITE with the first SDP offer 
indicating all desired media and codecs that 
UE B supports 






3 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 


























INVITE triggers the OCB IPC in IMS B 


4 










f 








INVITE 


IMS B forwards the INVITE to IMS B AS 


^ 


5 


100 Trying 


AS optionally responds with a 100 Trying 
provisional response 




6 


603 Decline 


IMS B AS returns 603 Decline to IMS B 




7 


603 Decline 


IMS B forwards the 603 Decline to UE B 






8 








« 












User B is informed that call was declined 


9 












V 






ACK 


UE B sends ACK to IMS B 






10 


ACK 


IMS_B forwards ACK to IMS_B AS 
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4.4.6.3 



UC_07_R: SIP message flow for SS OCB with CF_ROAM_AS 



The expected call flow sequence is: 



Step 


Direction 


Message 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


1 

M 
S 
B 


A 
S 
B 






1 




















User B calls User A 


^ 


2 


















INVITE 


UE_B sends INVITE with the first SDP offer 
indicating all desired media and codecs that 
UE B supports 


f 


3 


100 Trying 


IIVIS_A responds with a 100 Trying provisional 
response 




4 


INVITE 


IMS A forwards INVITE to IMS B 


^ 


5 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 
























INVITE triggers the OCB IPC in IMS B 


6 












f 


N 




INVITE 


IMS B forwards the INVITE to IMS B AS 


f 


7 


100 Trying 


AS optionally responds with a 100 Trying 
provisional response 




8 


603 Decline 


IMS B AS returns 603 Decline to IMS B 




9 


603 Decline 


IMS B forwards the 603 Decline to IMS A 




10 


603 Decline 


IMS A forwards the 603 Decline to UE B 








11 




« 
















User B is informed that call was declined 


12 














V 




ACK 


UE B sends ACK to IMS A 








13 


ACK 


IMS A forwards ACK to IMS B 




14 


ACK 


IMS B forwards ACK to IMS B AS 

























4.4.7 Supplementary Service Originating Identification Presentation (OIP) 



4.4.7.1 



Description 



UE_A places an IMS VoIP call to UE_B. UE_B is subscribed to OIP service. The call flow path and node configuration 
for this use case corresponds to CF_INT_AS when UE_B is in home network and to CF_ROAM_AS when UE_B is 
roaming in IMS_A. 

The test sequence typically associated with this use case when is as follows (CFW step numbers refer the call flow step 
numbering). 



Step 


Action 


CF INT AS 


CF ROAM AS 


1 


User A calls User B 


Stepi 


Stepi 


2 


User B is informed of incoming call of User A, user A's identity is 
displayed 


Step 1 2 


Step 14 


3 


User A is informed that UE_B is ringing 


Step 18 


Step 21 


4 


User B answers call 


Step 1 9 


Step 22 


5 


User A is informed that call has been answered 


Step 25 


Step 29 


6 


User B is informed that the call is established 


Step 31 


Step 36 


7 


User A ends call 


Step 32 


Step 37 


8 


User B is informed that call has ended 


Step 38 


Step 44 


9 


User A is informed that call has ended 


Step 44 


Step 51 
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4.4.7.2 



UC_08_I: SIP message flow for SS OIP with CF_INT_AS 



The expected call flow sequence is: 



Step 


Direction 


Message 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


u 

E 
B 


1 

M 
S 
A 


1 

M 
S 
B 


A 
S 
B 






1 




> 
















User A calls User B 


2 










>. 








INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired media and codecs that 
UE A supports 


f 






3 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 








4 


INVITE 


IMS A forwards INVITE to IMS B 


^ 


5 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 
























INVITE triggers the OIP IPC in IMS B 


6 










^ 








INVITE 


IMS B forwards the INVITE to IMS B AS 


f 


7 


100 Trying 


AS optionally responds with a 100 Trying 
provisional response 




8 


INVITE 


IMS B AS returns, possibly modified, INVITE to 
IMS B 




9 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 




10 


INVITE 


IMS B forwards the INVITE to UE B 






11 


100 Trying 


UE_B optionally responds with a 100 Trying 
provisional response 






12 




















User B is informed of incoming call of User A, 
User A's identity is displayed 


k 




13 






f 












180 Ringing 


UE_B responds to initial INVITE with 180 
Ringing to indicate that it has started alerting 




^ 


14 


180 Ringing 


IMS B forwards 180 Ringing response to 
IMS_B AS 




15 


180 Ringing 


IMS B AS forwards 180 Ringing response to 
IMS_B 




16 


180 Ringing 


IMS B forwards the 1 80 Ringing response to 
IMS A 




17 


180 Ringing 


IMS A forwards the 1 80 Ringing response to 
UE A 








18 




« 
















User A is informed that UE B is ringing 


19 






User B answers call 


^ 


20 


















200 OK 


UE_B responds INVITE with 200 OK to indicate 
that the call has been answered 




^ 


21 


200 OK 


IMS_B forwards 200 OK response to IMS_B AS 




22 


200 OK 


IMS_B AS forwards 200 OK response to IMS_B 




23 


200 OK 


IMS B forwards the 200 OK response to IMS A 




24 


200 OK 


IMS A forwards the 200 OK response to UE A 








25 




i 
















User A is informed that call has been answered 


26 












■N. 






ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 








27 


ACK 


IMS A forwards ACK to IMS B 




28 


ACK 


IMS_B forwards ACK to IMS_B AS 




29 














f 




ACK 


IMS B AS forwards, possibly modified, ACK to 
IMS_B 




30 


ACK 


IMS B forwards ACK to UE B 






31 




> 




k 












User B is informed that the call is established 


32 






User A ends call 


33 


















BYE 


UE A releases the call with BYE 








34 












^ 






BYE 


IMS A forwards BYE to IMS B 
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Step 


Direction 


Message 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


1 

M 
S 
B 


A 
S 
B 






35 










^ 








BYE 


IMS_B forwards BYE to IMS_B AS 




36 


BYE 


IMS B AS forwards, possibly modified, BYE to 
IMS_B 




37 


BYE 


IMS A forwards BYE to UE B 






38 








« 












User B is informed that call has ended 


39 


















200 OK 


UE B sends 200 OK for BYE 




^ 


40 


200 OK 


IMS_B forwards 200 OK response to IMS_B AS 


f 


41 


200 OK 


IMS_B AS forwards 200 OK response to IMS_B 




42 


200 OK 


IMS B forwards the 200 OK response to IMS A 




43 


200 OK 


IMS A forwards the 200 OK response to UE A 








44 
































User A is informed that call has ended 



4.4.7.3 



UC_08_R: SIP message flow for SS OIP with CF_ROAM_AS 



The expected call flow sequence is: 



Step 


Direction 


Message 


Comment 


-| 


U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


1 

M 
S 

B 


A 
S 
B 




1 Iqpr A ralk 1 l<;pr R 


2 












^. 






INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired media and codecs that 
UE A supports 








3 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 








4 


INVITE 


IMS A forwards INVITE to IMS B 




5 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 
























INVITE triggers the OIP IPC in IMS B 


6 










f 








INVITE 


IMS B forwards the INVITE to IMS B AS 




7 


100 Trying 


AS optionally responds with a 100 Trying 
provisional response 


^ 


8 


INVITE 


IMS B AS returns, possibly modified, INVITE to 
IMS B 


V 


9 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 




10 


INVITE 


IMS B forwards the INVITE to IMS A 


>. 


11 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




12 


INVITE 


IMS A forwards the INVITE to UE B 




13 


100 Trying 


UE_B optionally responds with a 100 Trying 
provisional response 




14 








^ 












User B is informed of incoming call of User A, 
User A's identity is displayed 




15 










N. 


>. 






180 Ringing 


UE_B responds to initial INVITE with 180 
Ringing to indicate that it has started alerting 




16 


180 Ringing 


IMS A forwards 180 Ringing response to 
IMS B 




17 


180 Ringing 


IMS B forwards 180 Ringing response to 
IMS_B AS 




18 














/ 




180 Ringing 


IMS B AS forwards 180 Ringing response to 
IMS_B 
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Step 


Direction 


Message 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


1 

M 
S 
B 


A 
S 
B 






19 


















180 Ringing 


IMS B forwards the 1 80 Ringing response to 
IIVIS A 




20 


180 Ringing 


IIVIS A forwards the 1 80 Ringing response to 
UE A 








21 




i 
















User A is informed that UE B is ringing 


22 






User B answers call 


^ 


23 














V 




200 OK 


UE_B responds INVITE with 200 OK to indicate 
that the call has been answered 




24 


200 OK 


IMS A forwards 200 OK response to IMS B 


f 


25 


200 OK 


IMS_B forwards 200 OK response to IMS_B AS 




26 


200 OK 


IMS_B AS forwards 200 OK response to IMS_B 




27 


200 OK 


IMS B forwards the 200 OK response to IMS A 




28 


200 OK 


IMS_A forwards the 200 OK response to UE_A 








29 




« 
















User A is informed that call has been answered 


30 












>. 






ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 








31 


ACK 


IMS A forwards ACK to IMS B 




32 


ACK 


IMS_B forwards ACK to IMS_B AS 




33 












^ 






ACK 


IMS B AS forwards, possibly modified, ACK to 
IMS_B 




34 


ACK 


IMS B forwards ACK to IMS A 




35 


ACK 


IMS A forwards ACK to UE B 




36 




» 




i 












User B is informed that the call is established 


37 






User A ends call 


38 












>. 






BYE 


UE A releases the call with BYE 






f 


39 


BYE 


IMS A forwards BYE to IMS B 




40 


BYE 


IMS_B forwards BYE to IMS_B AS 


f 


41 


BYE 


IMS B AS forwards, possibly modified, BYE to 
IMS_B 




42 


BYE 


IMS B forwards BYE to IMS A 




43 


BYE 


IMS A forwards BYE to UE B 




44 








i 












User B is informed that call has ended 


45 












^. 






200 OK 


UE B sends 200 OK for BYE 




46 


200 OK 


IMS A forwards 200 OK response to IMS B 




47 


200 OK 


IMS_B forwards 200 OK response to IMS_B AS 


f 


48 


200 OK 


IMS_B AS forwards 200 OK response to IMS_B 




49 


200 OK 


IMS B forwards the 200 OK response to IMS A 




50 


200 OK 


IMS A forwards the 200 OK response to UE A 








51 
































User A is informed that call has ended 



4.4.8 Supplementary Service Originating Identification Restriction (OIR) 



4.4.8.1 



Description 



UE_B places an IMS VoIP call to UE_A. UE_A is subscribed to OIP service, UE_B is subscribed to OIR service in 
permanent mode or default presentation restricted temporary mode. The call flow path and node configuration for this 
use case corresponds to CF_INT_AS when UE_B is in home network and to CF_ROAM_AS when UE_B is roaming in 
IMS_A. 

The test sequence typically associated with this use case is as follows (CFW step numbers refer the call flow step 
numbering). 
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Step 


Action 


CF INT AS 


CF ROAM AS 


1 


User B calls User A 


Step 1 


Step 1 


2 


User A is Informed of Incoming call of User B, user B's Identity 
is not displayed 


Step 1 7 


Step 18 


3 


User B is informed that UE A is ringing 


Step 25 


Step 27 


4 


User A answers call 


Step 26 


Step 28 


5 


User B is Informed that call has been answered 


Step 34 


Step 37 


6 


User A is informed that the call is established 


Step 42 


Step 46 


7 


User A ends call 


Step 43 


Step 47 


8 


User B is Informed that call has ended 


Step 51 


Step 56 


9 


User A is Informed that call has ended 


Step 59 


Step 65 



4.4.8.2 



UC_09_I: SIP message flow for SS OIR with CF_INT_AS 



The expected call flow sequence is: 



Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


A 
S 
A 


1 

M 
S 
B 


A 
S 
B 






1 








» 














User B calls User A 


2 




















INVITE 


UE_B sends INVITE with the first SDP 
offer indicating all desired media and 
codecs that UE B supports 


^ 






3 


100 Trying 


IIVIS_B responds with a 100 Trying 
provisional response 






























INVITE triggers the OIR IPC in IMS B 


4 
















N 




INVITE 


IMS B forwards the INVITE to IMS B AS 


^ 


5 


100 Trying 


IMS_B AS optionally responds with a 100 
Trying provisional response 


^ 


6 


INVITE 


IMS_B AS returns modified INVITE 
including Privacy header (value "id" or 
"header") to IMS B 


V 


7 


100 Trying 


IMS_B responds with a 100 Trying 
provisional response 




8 


INVITE 


IMS B forwards the INVITE to IMS A 






9 


100 Trying 


IMS_A responds with a 100 Trying 
provisional response 




























INVITE triggers the OIP IPC in IMS A 


10 




















INVITE 


IMS A forwards the INVITE to IMS A AS 




11 


100 Trying 


IMS A AS optionally responds with a 1 00 
Trying provisional response 




12 


INVITE 


IMS_A AS returns modified INVITE 
including modified Prom and P-Asserted 
headers to IMS A 




13 


100 Trying 


IMS_A responds with a 100 Trying 
provisional response 




14 


INVITE 


IMS A forwards the INVITE to UE A 










15 




















100 Trying 


UE_A optionally responds with a 100 
Trying provisional response 










17 






















User A is informed of incoming call of 
User B, user B's identity is not displayed 




18 




















180 Ringing 


UE_A responds to initial INVITE with 180 
Ringing to indicate that it has started 
alerting 










19 


180 Ringing 


IMS A forwards the 1 80 Ringing to 
IMS A AS 




20 


180 Ringing 


IMS_A AS forwards, possibly modified, 
180 Ringing to IMS A 




21 


180 Ringing 


IMS A forwards 180 Ringing response to 
IMS B 




22 


180 Ringing 


IMS B forwards 180 Ringing response to 
IMS_B AS 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


u 

E 
A 


U 
s 
e 
r 
B 


u 

E 
B 


1 

M 
S 
A 


A 
S 
A 


1 

M 
S 
B 


A 
S 
B 






23 




















180 Ringing 


ll\/IS_B AS forwards, possibly modified, 
180 Ringing response to IIVIS_B 




24 


180 Ringing 


ll\/IS_B forwards the 180 Ringing 
response to UE_B 








25 




» 




« 














User B is informed tliat UE A is ringing 


26 






User A answers call 


27 












V 








200 OK 


UE_A responds INVITE with 200 OK to 
indicate that the call has been answered 








>. 


28 


200 OK 


IMS A forwards the 200 OK to IMS A AS 




29 
















V 




200 OK 


IMS A AS forwards, possibly modified, 
200 OK to IMS A 




30 


200 OK 


IMS A forwards 200 OK response to 
IMS B 




31 


200 OK 


IMS B forwards 200 OK response to 
IMS_B AS 




32 


200 OK 


IMS_B AS forwards, possibly modified, 
200 OK response to IMS_B 




33 


200 OK 


IMS B forwards the 200 OK response to 
UE B 








34 






















User B is informed that call has been 
answered 


i 




35 




















ACK 


UE B acknowledges the receipt of 200 
OK for INVITE 




^ 




36 


ACK 


IMS_B forwards ACK to IMS_B AS 




37 


ACK 


IMS B AS forwards, possibly modified, 
ACK to IMS_B 




38 


ACK 


IMS B forwards ACK to IMS A 






39 


ACK 


IMS A forwards the ACK to IMS A AS 


^ 


40 


ACK 


IMS A AS forwards, possibly modified, 
ACK to IMS A 




41 


ACK 


IMS A forwards ACK to UE A 










42 






















User A is informed that the call is 
established 


i 


> 


43 




User A ends call 


44 












V 




^ 




BYE 


UE A releases the call with BYE 








45 


BYE 


IMS A forwards BYE to IMS A AS 


^ 


46 


BYE 


IMS A AS forwards, possibly modified, 
BYE to IMS_A 




47 


BYE 


IMS_A forwards BYE to IMS_B 






48 


BYE 


IMS B forwards BYE to IMS B AS 




49 


BYE 


IMS B AS forwards, possibly modified, 
BYE to IMS B 




50 




















BYE 


IMS A forwards BYE to UE B 








51 








« 














User B is informed that call has ended 


52 














^. 






200 OK 


UE B sends 200 OK for BYE 








53 


200 OK 


IMS B forwards 200 OK response to 
IMS_B AS 


f 


54 


200 OK 


IMS_B AS forwards, possibly modified, 
200 OK response to IMS_B 




55 


200 OK 


IMS B forwards the 200 OK response to 
IMS A 


^. 




56 


200 OK 


IMS A forwards the 200 OK to IMS A AS 




57 


200 OK 


IMS A AS forwards, possibly modified, 
200 OK to IMS A 




58 


200 OK 


IMS A forwards the 200 OK response to 
UE A 








59 




i 


















User A is informed that call has ended 
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4.4.8.3 



UC_09_R: SIP message flow for SS OIR with CF_ROAM_AS 



The expected call flow sequence is: 



Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


A 
S 
A 


1 

M 
S 
B 


A 
S 
B 






1 








^ 














User B calls User A 


2 




















INVITE 


UE_B sends INVITE with the first SDP 
offer indicating all desired media and 
codecs that UE B supports 




3 


100 Trying 


IMS_A responds with a 100 Trying 
provisional response 




4 


INVITE 


IMS A forwards INVITE to IMS B 






5 


100 Trying 


IMS_B responds with a 100 Trying 
provisional response 




























INVITE triggers the OIR IPC in IMS B 


6 




















INVITE 


IMS B forwards the INVITE to IMS B AS 




7 


100 Trying 


IMS_B AS optionally responds with a 100 
Trying provisional response 




8 


INVITE 


IMS_B AS returns modified INVITE 
including Privacy header (value "id" or 
"header") to IMS B 




9 


100 Trying 


IMS_B responds with a 100 Trying 
provisional response 




10 


INVITE 


IMS B forwards the INVITE to IMS A 




>. 


11 


100 Trying 


IMS_A responds with a 100 Trying 
provisional response 




























INVITE triggers the OIP IPC in IMS A 


12 




















INVITE 


IMS A forwards the INVITE to IMS A AS 




13 


100 Trying 


IMS A AS optionally responds with a 1 00 
Trying provisional response 




14 


INVITE 


IMS_A AS returns modified INVITE 
including modified Prom and P-Asserted 
headers to IMS A 




15 


100 Trying 


IMS_A responds with a 100 Trying 
provisional response 




16 


INVITE 


IMS A forwards the INVITE to UE A 










17 




















100 Trying 


UE_A optionally responds with a 100 
Trying provisional response 










18 






















User A is informed of incoming call of 
User B, user B's identity is not displayed 




19 




















180 Ringing 


UE_A responds to initial INVITE with 180 
Ringing to indicate that it has started 
alerting 




« 






20 


180 Ringing 


IMS A forwards the 1 80 Ringing to 
IMS A AS 




21 


180 Ringing 


IMS_A AS forwards, possibly modified, 
180 Ringing to IMS A 


^ 


22 


180 Ringing 


IMS A forwards 180 Ringing response to 
IMS B 




23 


180 Ringing 


IMS B forwards 180 Ringing response to 
IMS_B AS 




24 


180 Ringing 


IMS_B AS forwards, possibly modified, 
180 Ringing response to IMS_B 




25 


180 Ringing 


IMS_B forwards the 180 Ringing 
response to IMS A 




26 
27 


180 Ringing 


IMS_A forwards the 180 Ringing 

response to UE B 

User B is informed that UE A is ringing 




28 






-^ 






























User A answers call 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


u 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


A 
S 
A 


1 

M 
S 
B 


A 
S 
B 






29 




















200 OK 


UE_A responds INVITE with 200 OK to 
indicate that the call has been answered 










30 


200 OK 


IMS A forwards the 200 OK to IMS A AS 




31 




















200 OK 


IMS A AS forwards, possibly modified, 
200 OK to IMS A 




32 


200 OK 


IMS A forwards 200 OK response to 
IMS B 






33 


200 OK 


IMS B forwards 200 OK response to 
IMS_B AS 




34 


200 OK 


IMS_B AS forwards, possibly modified, 
200 OK response to IMS_B 




35 


200 OK 


IMS B forwards the 200 OK response to 
IMS A 






36 


200 OK 


IMS A forwards the 200 OK response to 
UE B 




37 






















User B is informed that call has been 
answered 


i 




38 




















ACK 


UE B acknowledges the receipt of 200 
OK for INVITE 




39 


ACK 


IMS A forwards ACK to IMS B 






40 


ACK 


IMS_B forwards ACK to IMS_B AS 




41 


ACK 


IMS B AS forwards, possibly modified, 
ACKtolMS_B 




42 


ACK 


IMS B forwards ACK to IMS A 






43 


ACK 


IMS A forwards the ACK to IMS A AS 




44 


ACK 


IMS A AS forwards, possibly modified, 
ACK to IMS A 




45 


ACK 


IMS A forwards ACK to UE A 








46 






















User A is informed that the call is 
established 


i 


> 


47 




User A ends call 


48 




















BYE 


UE A releases the call with BYE 








49 


BYE 


IMS A forwards BYE to IMS A AS 




50 


BYE 


IMS A AS forwards, possibly modified, 
BYE to IMS_A 




51 














N. 






BYE 


IMS_A forwards BYE to IMS_B 






52 


BYE 


IMS B forwards BYE to IMS B AS 




53 


BYE 


IMS B AS forwards, possibly modified, 
BYE to IMS B 




54 


BYE 


IMS B forwards BYE to IMS A 






55 


BYE 


IMS A forwards BYE to UE B 




56 








« 














User B is informed that call has ended 


57 




















200 OK 


UE B sends 200 OK for BYE 




58 


200 OK 


IMS A forwards 200 OK response to 
IMS B 






59 


200 OK 


IMS B forwards 200 OK response to 
IMS_B AS 




60 


200 OK 


IMS_B AS forwards, possibly modified, 
200 OK response to IMS_B 




61 


200 OK 


IMS B forwards the 200 OK response to 
IMS A 






62 


200 OK 


IMS A forwards the 200 OK to IMS A AS 




63 


200 OK 


IMS A AS forwards, possibly modified, 
200 OK to IMS A 




64 


200 OK 


IMS A forwards the 200 OK response to 
UE A 








65 




i — 
































User A is informed that call has ended 
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4.4.9 Supplementary Service HOLD 



4.4.9.1 



Description 



UE_A places an IMS VoIP call to UE_B which places the call on HOLD. UE_A will be notified by the AS that the call 
is on hold. UE_B will resume the call and UE_A will be informed by the AS that the call is resumed. 

The test sequence typically associated with this use case when is as follows (CFW step numbers refer the call flow step 
numbering). 



Step 


Action 


CF INT AS 


CF ROAM AS 


1 


User A calls User B 


1 


1 


2 


User B is Informed of incoming call of User A 


8 


10 


3 


User A is informed that UE B is ringing 


12 


15 


4 


User B answers call 


13 


16 


5 


User A is informed that call has been answered 


17 


21 


6 


User B is informed that call is established 


21 


26 


7 


User B puts call on hold 


22 


27 


8 


User A is informed that call on hold with AS 
tone 


33 


40 


9 


User B is informed that call on hold 


39 


47 


10 


User B resumes call 


45 


54 


11 


User B is informed that call is resumed 


61 


73 


12 


User A is informed that call is resumed 


67 


80 


13 


User A ends call 


68 


81 


14 


User B is informed that call has ended 


72 


86 


15 


User A is informed that call has ended 


76 


91 



4.4.9.1.1 



UC_10_I: SIP Call Flow "call hold and resume with AS tone" using relNVITE with 
CF INT AS 



The expected call flow sequence is: 



Step 


Direction 


Message 


Comment 




U 
s 

e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 
IVI 

s 

A 


1 
IVI 

s 

B 


A 
S 
B 






1 




















User A calls User B 




2 


















INVITE 


UE_A sends INVITE with the first SDP 
offer indicating all desired media and 
codecs that UE A supports 


f 






3 


100 Trying 


IIVIS_A responds with a 100 Trying 
provisional response 






f 


4 


INVITE 


IMS_A forwards INVITE to IMS_B 




5 


100 Trying 


IMS_B responds with a 100 Trying 
provisional response 




6 


INVITE 


IMS_A forwards INVITE to UE_B 






7 


100 Trying 


UE_B optionally responds with a 100 
Trying provisional response 






8 








^ 












User B is informed of incoming call of 
User A 




9 


















180 Ringing 


UE_B responds to initial INVITE with 180 
Ringing to indicate that it has started 
alerting 




^ 


10 


180 Ringing 


IIVIS B forwards the 180 Ringing response 
to IMS A 




11 


180 Ringing 


IMS_A P- forwards the 180 Ringing 
response to UE_A 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


u 

E 
B 


1 

M 
S 
A 


1 

IVI 
S 
B 


A 
S 
B 






12 




















User A is informed that UE_B is ringing 


i 




13 




User B answers call 


5 




14 












V 






200 OK 


UE_B responds to INVITE with 200 OK to 
indicate that the call has been answered 






15 


200 OK 


IMS B forwards 200 OK response to 
IMS A 




16 


200 OK 


IMS A forwards the 200 OK response to 
UE A 








17 




















User A is informed that call has been 
answered 


i 




18 










^. 








ACK 


UE A acknowledges the receipt of 200 
OK for INVITE 






^ 


19 


ACK 


IMS_A forwards ACK to IMS_B 




20 


ACK 


IMS_B forwards ACK to UE_B 






21 




















User B is informed that call is established 


i 




22 




User B puts call on hold 


5 




23 


















INVITE 


UE_B sends relNVITE message indicating 
media attribute "sendonly" (Call Hold) 






24 


100 Trying 


IMS_B responds with a 100 Trying 
provisional response 






25 


INVITE 


IMS_B sends relNVITE to AS_B 


f 


26 


100 Trying 


AS_B optionally responds with a 100 
Trying provisional response 


f 


27 


INVITE 


AS_B sends relNVITE to IMS_B 




28 






^ 












100 Trying 


IMS_B responds with a 100 Trying 
provisional response 




29 


INVITE 


IMS_B forwards relNVITE to IMS_A 


>. 


30 


100 Trying 


IMS_A responds with a 100 Trying 
provisional response 




31 


INVITE 


IMS_A forwards relNVITE to UE_A 








32 


100 Trying 


UE_A optionally responds with a 100 
Trying provisional response 








33 




















User A is informed that call is on hold with 
AS tone 


< 




34 










^. 


V 






200 OK 


UE_A responds to relNVITE with 200 OK 
indicating media attribute "recvonly" 








35 


200 OK 


IMS A forwards 200 OK response to 
IMS B 




36 


200 OK 


IMS B forwards 200 OK response to 
AS B 




37 


200 OK 


AS B forwards 200 OK response to 
IMS B 




38 


200 OK 


IMS_b forward the 200 OK to UE_B 






39 








f 












User B is informed that the call is on hold 




40 














V 




ACK 


UE B acknowledges the receipt of 200 
OK for relNVITE 






41 


ACK 


IMS_B forwards ACK to AS_B 




42 


ACK 


AS_B forwards ACK to IMS_B 
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Step 


Direction 


Message 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


u 

E 
B 


1 
IVI 

s 

A 


1 

IVI 

s 

B 


A 
S 
B 






43 












f 






ACK 


IMS_B forwards ACK to IMS_A 




44 


ACK 


IMS_A forwards ACK to UE_A 








45 




















User B resumes call 


5 




46 


















INVITE 


UEB sends second relNVITE message 
indicating media attribute "sendrecv" (Call 
Resume) 






47 


100 Trying 


IMS_B responds with a 100 Trying 
provisional response 




f 


48 


INVITE 


IMS_B sends relNVITE to AS_B 


^ 


49 


100 Trying 


AS_B optionally responds with a 100 
Trying provisional response 




50 


INVITE 


AS_B forwards INVITE to IMS_B 




51 


100 Trying 


IMS_B responds with a 100 Trying 
provisional response 




52 


INVITE 


IMS_B sends relNVITE to IMS_A 


N. 


53 


100 Trying 


IMS_A responds with a 100 Trying 
provisional response 




54 


INVITE 


IMS_A forwards relNVITE to UE_A 








55 


100 Trying 


UE_A optionally responds with a 100 
Trying provisional response 








56 


200 OK 


UEA sends the 200 OK indicating media 
attribute "sendrecv" to IIVIS A 








57 


200 OK 


IMS A forwards 200 OK response to 
IMS B 




58 


200 OK 


IMS B forwards 200 OK response to 
AS B 




59 










^ 








200 OK 


AS_B forwards the 200 OK for INVITE 




60 


200 OK 


IMS_B forwards 200 OK to UE_B 






61 




















User B is informed that call is resumed 


k 




62 






f 












ACK 


UE_B sends ACK to IMS_B 






63 


ACK 


IMS_B forwards ACK to AS_B 




64 


ACK 


AS_B forwards ACK to IMS_B 




65 


ACK 


IMS_B forwards ACK to IMS_A 




66 


ACK 


IMS_A forwards ACK to UE_A 








67 


















ACK 


User A is informed that call resumed 


^ 




68 




User A ends call 




69 


















BYE 


UE_A releases the call with BYE 






^ 


70 


BYE 


IMS_A forwards BYE to IMS_B 




71 


BYE 


IMS_B forwards BYE to UE_B 






72 




















User B is informed that call has ended 




73 


















200 OK 


UE_B sends 200 OK for BYE 
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Step 


Direction 


Message 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 
IVI 

s 

A 


1 
IVI 

s 

B 


A 
S 
B 






74 


















200 OK 


IMS B forwards 200 OK response to 
IMS A 




75 


200 OK 


IMS A forwards the 200 OK response to 
UE A 








76 




















User A is informed that call has ended 

















4.4.9.1 .2 UC_1 0_R: SIP Call Flow "call hold and resume with AS tone" using relNVITE 

with CF_ROAM_AS 

The expected call flow sequence is: 



Step 


Direction 


Message 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


u 

E 
B 


1 

M 
S 
A 


1 

M 
S 
B 


A 
S 
B 






1 




















User A calls User B 




2 












^ 






INVITE 


UE_A sends INVITE with the first SDP 
offer indicating all desired media and 
codecs that UE A supports 


f 






3 


100 Trying 


IMS_A responds with a 100 Trying 
provisional response 








4 


INVITE 


IMS_A forwards INVITE to IMS_B 




5 


100 Trying 


IMS_B responds with a 100 Trying 
provisional response 




6 


INVITE 


IMS_B forwards INVITE to IMS_A 




7 










^ 


V 






100 Trying 


IMS_A responds with a 100 Trying 
provisional response 




8 


INVITE 


IMS_A forwards INVITE to UE_B 




9 


100 Trying 


UE_B optionally responds with a 100 
Trying provisional response 




10 




















User B is informed of incoming call of 
User A 


k 




11 


















180 Ringing 


UE_B responds to initial INVITE with 180 
Ringing to indicate that it has started 
alerting 




12 


180 Ringing 


IMS A forwards 180 Ringing response to 
IMS B 


f 


13 


180 Ringing 


IMS B forwards the 180 Ringing response 
to IMS A 




14 


180 Ringing 


IMS A forwards the 180 Ringing response 
toUE A 








15 




















User A is informed that UE_B is ringing 


^ 




16 




User B answers call 


> 




17 












V 






200 OK 


UE_B responds to INVITE with 200 OK to 
indicate that the call has been answered 




18 


200 OK 


IMS A forwards 200 OK response to 
IMS B 




19 


200 OK 


IMS B forwards 200 OK response to 
IMS A 




20 


200 OK 


IMS A forwards the 200 OK response to 
UE A 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


u 

E 
B 


1 

M 
S 
A 


1 

IVI 

s 

B 


A 
S 
B 






21 




















User A Is informed that call has been 
answered 


i 




22 


















ACK 


UE A acknowledges the receipt of 200 
OK for INVITE 








23 


ACK 


IMS_A forwards ACK to IMS_B 


^ 


24 


ACK 


IMS_B forwards ACK to IMS_A 




25 


ACK 


IMS_A forwards ACK to UE_B 




26 




















User B is informed that call is established 


i 




27 




User B puts call on hold 


5 




28 


















INVITE 


UE_B sends relNVITE message indicating 
media attribute "sendonly" (Call Hold) 




29 


100 Trying 


IMS_A responds with a 100 Trying 
provisional response 




30 


INVITE 


IMS_A forwards INVITE to IMS_B 




31 


100 Trying 


IMS_B responds with a 100 Trying 
provisional response 




32 


INVITE 


IMS_B sends relNVITE to AS_B 


f 


33 


100 Trying 


AS_B optionally responds with a 100 
Trying provisional response 




35 


INVITE 


AS_B sends relNVITE to IMS_B 




35 


100 Trying 


IMS_B responds with a 100 Trying 
provisional response 




36 


INVITE 


IMS_B forwards relNVITE to IMS_A 




37 












N. 






100 Trying 


IMS_A responds with a 100 Trying 
provisional response 




38 


INVITE 


IMS_A forwards relNVITE to UE_A 








39 


100 Trying 


UE_A optionally responds with a 100 
Trying provisional response 








40 




















User A is informed that call is on hold with 
AS tone 


^ 




41 












■N. 






200 OK 


UE_A responds to relNVITE with 200 OK 
indicating media attribute "recvonly" 








42 


200 OK 


IMS A forwards 200 OK response to 
IMS B 




43 


200 OK 


IMS B forwards 200 OK response to 
AS B 


f 


44 


200 OK 


AS B forwards 200 OK response to 
IMS B 




45 


200 OK 


IMS B forwards 200 OK response to 
IMS A 




46 


200 OK 


IMS_A forward the 200 OK to UE_B 




47 




















User B is informed that the call is on hold 




48 












N 






ACK 


UE B acknowledges the receipt of 200 
OK for relNVITE 




49 


ACK 


IMS_A forwards ACK to IMS_B 




50 


ACK 


IMS_B forwards ACK to AS_B 




51 


ACK 


AS_B forwards ACK to IMS_B 
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Step 


Direction 


Message 


Comment 




U 
s 
e 
r 
A 


u 

E 
A 


U 
s 
e 
r 
B 


u 

E 
B 


1 

IVI 

s 

A 


1 
IVI 

s 

B 


A 
S 
B 






52 












f 






ACK 


IMS_B forwards ACK to IMS_A 




53 


ACK 


IMS_A forwards ACK to UE_A 








54 




















User B resumes call 


5 




55 






f 






V 






INVITE 


UEB sends second relNVITE message 
indicating media attribute "sendrecv" (Call 
Resume) 




56 


100 Trying 


IMS_A responds with a 100 Trying 
provisional response 




57 


INVITE 


IMS_A sends relNVITE to IMS_B 


^ 


58 


100 Trying 


IMS_B responds with a 100 Trying 
provisional response 




59 


INVITE 


IMS_B sends relNVITE to AS_B 




60 


100 Trying 


AS_B optionally responds with a 100 
Trying provisional response 


f 


61 


INVITE 


AS_B forwards INVITE to IMS_B 


N. 


62 


100 Trying 


IMS_B responds with a 100 Trying 
provisional response 




63 


INVITE 


IMS_B sends relNVITE to IMS_A 




64 


100 Trying 


IMS_A responds with a 100 Trying 
provisional response 




65 


INVITE 


IMS_A forwards relNVITE to UE_A 








66 


100 Trying 


UE_A optionally responds with a 100 
Trying provisional response 








67 


200 OK 


UEA sends the 200 OK indicating media 
attribute "sendrecv" to IIVIS A 








68 










^ 


V 






200 OK 


IMS A forwards 200 OK response to 
IMS B 




69 


200 OK 


IMS B forwards 200 OK response to 
AS B 


f 


70 


200 OK 


AS_B forwards the 200 OK for INVITE 




71 


200 OK 


IMS_B forwards 200 OK to IMS_A 




72 


200 OK 


IMS_A forwards 200 OK to UE_B 




73 




















User B is informed that call is resumed 


k 




74 












>. 


V 




ACK 


UE_B sends ACK to IMS_A 




75 


ACK 


IMS_A forwards ACK to IMS_B 


^ 


76 


ACK 


IMS_B forwards ACK to AS_B 




77 


ACK 


AS_B forwards ACK to IMS_B 




78 


ACK 


IMS_B forwards ACK to IMS_A 




79 


ACK 


IMS_A forwards ACK to UE_A 








80 


















ACK 


User A is informed that call resumed 


i 




81 




User A ends call 




82 










N 








BYE 


UE_A releases the call with BYE 
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Step 


Direction 


Message 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 
IVI 

s 

A 


1 
IVI 

s 

B 


A 
S 
B 






83 










^ 








BYE 


IMS_A forwards BYE to IMS_B 




84 


BYE 


IMS_B forwards BYE to IMS_A 




85 


BYE 


IMS_A forwards BYE to UE_B 




86 




















User B is informed that call has ended 




87 


















200 OK 


UE_B sends 200 OK for BYE 




88 


200 OK 


IMS A forwards 200 OK response to 
IMS B 




89 


200 OK 


IMS B forwards 200 OK response to 
IMS A 




90 


200 OK 


IMS A forwards the 200 OK response to 
UE A 








91 




















User A is informed that call has ended 

























4.4.10 Supplementary Service Call Forward Unconditional (CFU) 
4.4.10.1 Description 

UE_A places an IMS VoIP call to UE_B which has CFU activated towards user UE_B2 which is located in IMS_A. 
UE_A may be notified by the AS that the call is forwarded. UE_B2 answers the call without previous ringing 
indication. The call is released by UE_A. 

The test sequence typically associated with this use case when is as follows (CFW step numbers refer the call flow step 
numbering). 



Step 


Action 


CF INT AS 


CF ROAM AS 


1 


User A calls User B 


1 


1 


2 


User A may be informed of call diversion 


11 


11 


3 


User B2 is informed of incoming call of User A 


16 


18 


4 


User B2 answers call 


17 


19 


5 


User A is informed that call has been answered 


23 


26 


6 


User B2 is informed that call is established 


29 


32 


7 


User A ends call 


30 


33 


8 


User B2 is informed that call has ended 


34 


37 


9 


User A is informed that call has ended 


38 


42 



4.4.1 0.1 .1 UC_1 1_l: SIP Call Flow "Communication Forwarding unconditional" with 

CF_INT_AS 

The expected call flow sequence is: 



Step 


Direction 


Message 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B2 


U 
E 
B2 


1 

M 
S 
A 


1 

M 
S 
B 


A 
S 
B 






1 




















User A calls User B 


^ 


2 


















INVITE 


UE_A sends INVITE with the first SDP 
offer indicating all desired media and 
codecs that UE A supports 
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Step 


Direction IVIessage 


Comment 




U 
s 
e 
r 
A 


u 

E 
A 


U 
s 
e 
r 
B2 


U 
E 
B2 


1 

M 
S 
A 


1 
IVI 

s 

B 


A 
S 
B 






3 






^ 












100 Trying 


IMS_A responds with a 100 Trying 
provisional response 








4 


INVITE 


IMS A forwards INVITE to IMS B 


^ 


5 


100 Trying 


IMS_B responds with a 100 Trying 
provisional response 
























INVITE triggers the CFU IPC in IMS B 


6 














^ 




INVITE 


IMS B forwards the INVITE to AS B 


f 


7 


100 Trying 


AS_B optionally responds with the 100 
Trying to IMS B 
























AS B applies the CDIV CFU procedure 


8 






^ 












181 Call is 

being 

forwarded 


AS_B indicates optionally to IMS_B that 
call has been forwarded 




9 


181 Call is 

being 

forwarded 


IMS_B indicates to IMS_A that call has 
been forwarded 




10 


181 Call is 

being 

forwarded 


IMS_A indicates that call to UE_B has 
been forwarded 








11 




« 
















User A may be informed of call diversion 


12 


















INVITE 


AS_B returns modified INVITE including 
new request URI and history header to 
IMS B 




13 


100 Trying 


IMS_B responds with a 100 Trying 
provisional response 




14 










^ 








INVITE 


IMS B forwards the INVITE to UE B2 




V 


15 


100 Trying 


UE_B2 optionally responds with a 100 
Trying provisional response 






16 




















User B2 is informed of incoming call of 
User A 


^ 




17 




User B2 answers call 


^ 


18 












^. 


^ 




200 OK 


UE_B2 responds to INVITE with 200 OK 
to indicate that the call has been 
answered 




^ 


19 


200 OK 


IMS B forwards 200 OK response to 
AS B 


f 


20 


200 OK 


AS B returns, possibly modified, 200 OK 
to IMS B 




21 


200 OK 


IMS B forwards 200 OK response to 
IMS A 




22 


200 OK 


IMS A forwards 200 OK response to 
UE A 








23 




















User A is informed that call has been 
answered 


i 




24 












>. 






ACK 


UE A acknowledges the receipt of 200 
OK for INVITE 








25 


ACK 


IMS A forwards ACK to IMS B 




26 


ACK 


IMS B forwards ACK to AS B 


f 


27 


ACK 


AS B returns, possibly modified, ACK to 
IMS B 




28 


ACK 


IMS B forwards ACK to UE B2 






29 




















User B2 is informed that call is 
established 


^ 




30 




User A ends call 


> 


31 










^. 








BYE 


UE A releases the call with BYE 






^ 


32 


BYE 


IMS A forwards BYE to IMS B 




33 


BYE 


IMS B forwards BYE to UE B 






34 








i 












User B is informed that call has ended 


35 












V 






200 OK 


UE B sends 200 OK for BYE 








/ 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B2 


U 
E 
B2 


1 

M 
S 
A 


1 
IVI 

s 

B 


A 
S 
B 






36 






f 






f 






200 OK 


IMS B forwards 200 OK response to 
IMS A 




37 


200 OK 


IMS A forwards the 200 OK response to 
UE A 








38 




« 
















User A is informed that call has ended 



4.4.1 0.1 .2 UC_1 1_R: SIP Call Flow "Communication Forwarding unconditional" with 

CF_ROAM_AS 

The expected call flow sequence is: 



Step 


Direction IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B2 


U 
E 
B2 


1 

M 
S 
A 


1 

M 
S 
B 


A 
S 
B 






1 




















User A calls User B 


> 


2 










■N. 








INVITE 


UE_A sends INVITE with the first SDP 
offer indicating all desired media and 
codecs that UE A supports 








3 












V 






100 Trying 


IMS_A responds with a 100 Trying 
provisional response 








4 


INVITE 


IMS A forwards INVITE to IMS B 




5 


100 Trying 


IMS_B responds with a 100 Trying 
provisional response 
























INVITE triggers the CPU IPC in IMS B 


6 


















INVITE 


IMS B forwards the INVITE to AS B 


f 


7 


100 Trying 


AS_B optionally responds with the 100 
Trying to IMS B 
























AS B applies the CDIV CPU procedure 


8 






^ 






^ 






181 Call is 

being 

forwarded 


AS_B indicates optionally to IMS_B that 
call has been forwarded 




9 


181 Call is 

being 

forwarded 


IMS_B indicates to IMS_A that call has 
been forwarded 




10 


181 Call is 

being 

forwarded 


IMS_A indicates that call to UE_B has 
been forwarded 








11 




k 
















User A may be informed of call diversion 


12 














f 




INVITE 


AS_B returns modified INVITE including 
new request URI and history header to 
IMS B 


V 


13 


100 Trying 


IMS_B responds with a 100 Trying 
provisional response 




14 


INVITE 


IMS B forwards the INVITE to IMS A 


■N. 


15 


100 Trying 


IMS_A responds with a 100 Trying 
provisional response 




16 


INVITE 


IMS A forwards the INVITE to UE B2 




17 


100 Trying 


UE_B2 optionally responds with a 100 
Trying provisional response 




18 




















User B2 is informed of incoming call of 
User A 


d 




19 




User B2 answers call 










^ 
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Step 


Direction IVIessage 


Comment 




U 
s 
e 
r 
A 


u 

E 
A 


U 
s 
e 
r 
B2 


U 
E 
B2 


1 

M 
S 
A 


1 

M 
S 
B 


A 
S 
B 






20 










>. 


N. 


^ 




200 OK 


UE_B2 responds to INVITE with 200 OK 
to indicate that the call has been 
answered 




21 


200 OK 


IMS A forwards 200 OK response to 
IMS B 




22 


200 OK 


IMS B forwards 200 OK response to 
AS B 


f 


23 


200 OK 


AS B returns, possibly modified, 200 OK 
to IMS B 




24 


200 OK 


IMS B forwards 200 OK response to 
IMS A 




25 


200 OK 


IMS A forwards 200 OK response to 
UE A 








26 




















User A is informed that call has been 
answered 


i 




27 










■N. 


>. 






ACK 


UE A acknowledges the receipt of 200 
OK for INVITE 




f 




28 


ACK 


IMS A forwards ACK to IMS B 




29 


ACK 


IMS B forwards ACK to AS B 


f 


30 


ACK 


AS B returns, possibly modified, ACK to 
IMS B 




31 


ACK 


IMS B forwards ACK to IMS A 




32 


ACK 


IMS B forwards ACK to UE B2 






33 




















User B2 is informed that call is 
established 


d 




34 




















User A ends call 


? 


35 












V 






BYE 


UE A releases the call with BYE 








36 


BYE 


IMS A forwards BYE to IMS B 




37 


BYE 


IMS B forwards BYE to IMS A 




38 


BYE 


IMS A forwards BYE to UE B 




39 








k 












User B is informed that call has ended 


40 






f 






N. 






200 OK 


UE B sends 200 OK for BYE 




41 


200 OK 


IMS A forwards 200 OK response to 
IMS B 


^ 


42 


200 OK 


IMS B forwards 200 OK response to 
IMS A 




43 


200 OK 


IMS A forwards the 200 OK response to 
UE A 








44 




« 
















User A is informed that call has ended 
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4.4.10.1.3 



UC_12: SIP Call Flow "Normal Call" with 2 UEs registered to same public identity 



The test sequence and expected call flow sequence when user A calls user B with 2 UEs, i.e. UE_B1 and UEB2, in an 
interworking scenario is: 



Step 


Action 


CF INT CALL 


1 


User A calls User B 


Step 1 


2 


User B is informed of incoming call of User A on UE B1 


Steps 


3 


User B is informed of incoming call of User A on UE B2 


Steps 


4 


User A is informed that a UE of User B is ringing 


Step 12 


5 


User B answers call on UE B2 


Step 13 


6 


User B is informed at UE B1 that the call is no longer offered 


Step 21 


7 


User A is informed that call has been answered 


Step 17 


8 


User B is informed that the call is established 


Step 21 


9A 


User A ends call 


Step 22A 


9B 


User B ends call 


Step 22B 


10A 


User B is informed that call has ended 


Step 26A 


10B 


User A is informed that call has ended 


Step 26B 


11A 


User A is informed that call has ended 


Step 30A 


11B 


User B is informed that call has ended 


Step SOB 



Note that steps 6 and 7 may happen in different order. 



Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

lUI 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






1 




> 














User A calls User B 


2 






V 




V 






INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired medias and codecs that 
UE A supports 


^ 


3 


100 Trying 


ll\/IS_A responds with a 100 Trying provisional 
response 




4 


INVITE 


IMS A forwards INVITE to IMS B 


^ 


5 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 




6 


INVITE 


IMS B forwards INVITE to UE B1 




7 


100 Trying 


UE_B1 optionally responds with a 100 Trying 
provisional response 




S 


















User B is informed on UEBI of incoming call of 
User A 


^ 




9 








y 


^ 






180 Ringing 


UE_B1 responds to initial INVITE with 180 
Ringing to indicate that it has started alerting 




10 


180 Ringing 


IMS B forwards 180 Ringing response to 
IMS A 




11 


180 Ringing 


IMS A forwards the 1 80 Ringing response to 
UE A 




12 




i 














User A is informed that a UE of User B Is ringing 


13 










V 






INVITE 


IMS B forwards INVITE to UE B2 




14 


100 Trying 


UE_B2 optionally responds with a 100 Trying 
provisional response 




15 


















User B is informed on UE_B2 of incoming call of 
User A 


^ 




16 






^ 




^ 






180 Ringing 


UE_B2 responds to initial INVITE with 180 
Ringing to indicate that it has started alerting 




17 


180 Ringing 


IMS B forwards 2"'^ 180 Ringing response to 
IMS A 




18 


180 Ringing 


IMS A forwards the 2"^ ISO Ringing response 
toUE A 




19 












i 






User B answers call at UE B2 


20 
















200 OK 


UE_B2 responds to INVITE with 200 OK to 
indicate that the call has been answered 


\. 


21 


CANCEL 


IMS B sends CANCEL request to UE B1 




/ 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


u 

s 
e 
r 
B 






22 








^ 








200 OK 


UE_B1 sends 200 OK response to the CANCEL 
request to IMS B 




23 




UE_B1 informs user B that the call is no longer 
offered to this UE and stops ringing 




24 


200 OK 


IMS B forwards 200 OK response to IMS A 




25 


200 OK 


IMS A forwards the 200 OK response to UE A 




26 




i 














User A is informed that call has been answered 


27 
















ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 




28 


ACK 


IMS A forwards ACK to IMS B 




29 


ACK 


IMS B forwards ACK to UE B 




30 












J 






User B is informed that the call is established 


31A 




» 














User A ends call 


32A 
















BYE 


UE A releases the call with BYE 




33A 


BYE 


IMS A forwards BYE to IMS B 




34A 


BYE 


IMS B forwards BYE to UE B 




35A 












? 






User B is informed that call has ended 


36A 






^ 




^ 






200 OK 


UE B sends 200 OK for BYE 




37A 


200 OK 


IMS B forwards 200 OK response to IMS A 




38A 


200 OK 


IMS A forwards the 200 OK response to UE A 




39A 




d 














User A is informed that call has ended 


31 B 


















User B ends call 


i 


32B 








^ 








BYE 


UE B releases the call with BYE 




338 


BYE 


IMS B forwards BYE to IMS A 




34B 


BYE 


IMS A forwards BYE to UE A 




35B 




i 














User A is informed that call has ended 


368 
















200 OK 


UE A sends 200 OK for BYE 




37B 


200 OK 


IMS A forwards 200 OK response to IMS B 




38B 


200 OK 


IMS_B forwards the 200 OK response to UE_B 




398 












^ 






User B is informed that call has ended 



Note that the call flow sequence steps 6 through 12 and 13 through 18 may occur in an interleaved fashion. In addition, 
steps 21 through 23 and steps 24 through 26 may also occur in an interleaved fashion. 

4.4.1 1 Addition of media stream 



4.4.11.1 



Description 



UE_A and UE_B are in an established session with one or more media streams. While in the established session, UE_A 
adds a new media stream. It is assumed that both UEs are registered in their respective networks. 
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The test sequence and expected call flow sequence for addition of multimedia stream can be illustrated when adding a 
new media stream, for example, adding a chat/text session during an existing IMS VoIP call. 



Step 


Action 


CF INT CALL 


1 


User A calls User B 


1 


2 


User B Is Informed of Incoming call of User A 


8 


3 


User A Is Informed that UE B Is ringing 


12 


4 


User B answers call 


13 


5 


User A Is Informed that call has been answered 


17 


6 


User B Is presented that call Is established 


21 


7A 


User A adds a new media stream 


22A 


7B 


User B adds a new media stream 


22B 


8A 


User B may be Informed to accept/reject new media stream 


29A 


8B 


User A may be Informed to accept/reject new media stream 


29B 


9A 


User A may be Informed that UE B Is alerting User B 


33A 


9B 


User B may be Informed that UE A Is alerting User A 


33B 


10A 


If Informed, User B accepts the new media stream 


34A 


108 


If Informed, User A accepts the new media stream 


34B 


11A 


User A Is Informed that new media stream has been accepted 


38A 


11B 


User B Is Informed that new media stream has been accepted 


38B 


12 


User A ends call 


42 


13 


User B Is Informed that call has ended 


46 


14 


User A Is Informed that call has ended 


50 



NOTE: The call flow sequences described in this section are not limited to multimedia stream handling scenarios 
where remote user interaction is required. In other words these call flow sequences may be observed for a 
call scenario where remote user interaction is not invoked. For example, these same call flows may apply 
to a scenario where a user removes the video stream from a multimedia audio+video session (remote user 
interaction is highly unlikely in this case but the same call flows illustrated in this section may be 
observed nevertheless). 



4.4.11.1.1 



UC_13: SIP Call Flow "Addition of media stream using relNVITE" 



The expected call flow sequence is: 



Step 


Direction 


Message 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


u 

s 
e 
r 
B 






1 




> 














User A calls User B 


2 










V 






INVITE 


UE_A sends INVITE with the first SDP offer 
Indicating all desired media and codecs that 
UE A supports 


^ 


3 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




4 


INVITE 


IMS A forwards the INVITE to IMS B 


^ 


5 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 




6 


INVITE 


IMS B forwards the INVITE to UE B 




7 
















100 Trying 


UE_B optionally responds with a 100 Trying 
provisional response 




8 












» 






User B is Informed of Incoming call of User A 


9 
















180 Ringing 


UE_B responds to Initial INVITE with 180 
Ringing 




10 


180 Ringing 


IMS B forwards the 1 80 Ringing response to 
IMS A 




11 


180 Ringing 


IMS A forwards the 1 80 Ringing response to 
UE A 




12 




i 














User A is Informed that UE B Is ringing 


13 






User B answers call 


i 


14 








f* 








200 OK 


UE B responds with 200 OK to INVITE 




15 


200 OK 


IMS_B forwards the 200 OK response to IMS_A 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


u 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


u 

E 
B 


U 
s 
e 
r 
B 






16 
















200 OK 


IMS_A forwards the 200 OK response to UE_A 




17 




i 














User A is informed that call has been answered 


18 








V 








ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 




19 


ACK 


IMS A forwards the ACK to IMS B 




20 


ACK 


IMS B forwards the ACK to UE B 




21 > User B is presented that call is established 


22A 




User A adds a new media stream 


> 


23A 








*. 








INVITE 


UE_A sends relNVITE message with new media 
stream in SDP 




24A 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




25A 


INVITE 


IMS A forwards the INVITE to IMS B 




26A 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 




27A 


INVITE 


IMS B forwards the INVITE to UE B 


^ 


28A 


100 Trying 


UE_B optionally responds with a 100 Trying 
provisional response 




29A 


















User B may be informed to accept/reject new 
media stream 


^ 




30A 






^ 


^ 








180 Ringing 


UE B responds to relNVITE with 180 Ringing 




31A 


180 Ringing 


IMS B forwards 180 Ringing response to 
IMS A 




32A 


180 Ringing 


IMS A forwards the 1 80 Ringing response to 
UE A 




33A 


















User A may be informed that UE B is alerting 
UserB 


^ 




34A 




If informed, User B accepts the new media 
stream 


i 




35A 






^ 




^ 






200 OK 


UE B responds with 200 OK to relNVITE 




36A 


200 OK 


IMS B forwards 200 OK response to IMS A 




37A 


200 OK 


IMS A forwards the 200 OK response to UE A 




38A 


















User A is informed that new media stream has 
been accepted 


^ 




39A 








V 








ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 




40A 
41A 


ACK 
ACK 


IMS A forwards the ACK to IMS B 
IMS B forwards the ACK to UE B 






22B 


















User B adds a new media stream 


^ 


238 










^ 






INVITE 


UE_B sends relNVITE message with new media 
stream in SDP 


N. 


24B 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 




25B 


INVITE 


IMS B forwards the relNVITE to IMS A 




26B 






^ 










100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




27B 
28B 


INVITE 
100 Trying 


IMS_A forwards the relNVITE to UE_A 
UE_A optionally responds with a 100 Trying 
provisional response 






29B 


















User A may be informed to accept/reject new 
media stream 


i 




30B 






>. 










180 Ringing 


UE A responds to relNVITE with 180 Ringing 




31B 


180 Ringing 


IMS A forwards the 1 80 Ringing response to 
IMS B 




32B 


180 Ringing 


IMS B forwards the 1 80 Ringing response to 
UE B 




33B 


















User B may be informed that UEA is alerting 
User A 


i 




34B 




If informed, User A accepts the new media 
stream 


; 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


u 

s 
e 
r 
B 






35B 
















200 OK 


UE A responds with 200 OK to relNVITE 




36B 


200 OK 


IMS A forwards the 200 OK response to IMS B 




37B 


200 OK 


IMS B forwards the 200 OK response to UE B 




38B 


















User B is informed that new media stream has 
been accepted 


5 




39B 








^ 








ACK 


UE B acknowledges the receipt of 200 OK for 
INVITE 




40B 
41B 


ACK 
ACK 


IMS B forwards the ACK to IMS A 
IMS A forwards the ACK to UE A 






42 




» 














User A releases the call 


43 
















BYE 


UE A sends BYE to IMS A 




44 


BYE 


IMS A forwards the BYE to IMS B 




45 


BYE 


IMS B forwards the BYE to UE B 




46 












J 






User B is informed that call has ended 


47 








^ 


^ 






200 OK 


UE B sends 200 OK for BYE 




48 


200 OK 


IMS B forwards 200 OK response to IMS A 




49 


200 OK 


IMS A forwards the 200 OK response to UE A 




50 




i 














User A is informed that call has ended 



4.4.12 Removal of media stream 



4.4.12.1 



Description 



UE_A and UE_B are in an established session with multiple media streams. While in the established session, UE_A 
removes a media stream. It is assumed that both UEs are registered in their respective networks. 

The test sequence and expected call flow sequence for multimedia session handling (when remote user interaction shall 
be avoided) can be illustrated when removing a media stream from a multimedia session with multiple streams 
(e.g. remove the chat/text stream from an IMS VoIP + chat multi-stream session). 



Step 


Action 


CF INT CALL 
Using UPDATE 


CF INT CALL 
Using relNVITE 


1 


User A initiates a multimedia session with at least two streams with User B 


1 


1 


2A 


User A removes one of the media streams 


42A 


42A 


2B 


User B removes one of the media streams 


42B 


42B 


3A 


User B is informed that the media stream has been removed 


46A 


49A 


3B 


User A is informed that the media stream has been removed 


46B 


49B 


4 


User A releases the call 


50 


56 


5 


User B is informed that call has ended 


54 


60 


6 


User A is informed that call has ended 


58 


64 



NOTE: The call flow sequences described in this section depict multimedia streaming handling scenarios where 
remote user interaction is not invoked. For example, remote user interaction is highly unlikely in an IMS 
VoIP audio session where a user decides to switch to some other audio codec. 

4.4.12.1.1 UC_14: SIP Call Flow "Removal of media streams using UPDATE" 

The expected call flow sequence is: 



Step 


Direction 


Message 


Comment 




U 


U 


1 


1 


U 


U 








s 


E 


M 


M 


E 


s 








e 


A 


S 


S 


B 


e 








r 




A 


B 




r 








A 










B 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






1 


















User A initiates a multimedia session with at 
least two streams with User B 


5 




42A 


















User A removes one of the media streams 


? 


43A 
















UPDATE 


UE A sends UPDATE to IMS A 




44A 


UPDATE 


IMS A forwards the UPDATE to IMS B 




45A 


UPDATE 


IMS B forwards the UPDATE to UE B 




46A 


















User B is informed that the media stream has 
been removed 


; 




47A 






^ 


y 








200 OK 


UE B responds with 200 OK to UPDATE 




48A 


200 OK 


IMS B forwards 200 OK response to IMS A 




49A 


200 OK 


IMS_A forwards the 200 OK response to UE_A 




42B 


















User B removes one of the media streams 


^ 


43B 








/■ 


f 






UPDATE 


UE B sends UPDATE to IMS B 




44B 


UPDATE 


IMS B forwards the UPDATE to IMS A 




458 


UPDATE 


IMS A forwards the UPDATE to UE A 




46B 


















User A is informed that the media stream has 
been removed 








47B 
















200 OK 


UE A responds with 200 OK to UPDATE 




48B 


200 OK 


IMS A forwards the 200 OK response to IMS B 




49B 


200 OK 


IMS_B forwards the 200 OK response to UE_B 




50 


















User A releases the call 


^ 


51 
















BYE 


UE A sends BYE to IMS A 




52 


BYE 


IMS A forwards the BYE to IMS B 




53 


BYE 


IMS B forwards the BYE to UE B 




54 












J 






User B is informed that call has ended 


55 








^ 


^ 






200 OK 


UE B sends 200 OK response for BYE 




56 


200 OK 


IMS B forwards the 200 OK response to IMS A 




57 


200 OK 


IMS A forwards the 200 OK response to UE A 




58 




« 














User A is informed that call has ended 



4.4.12.1.2 UC_15: SIP Call Flow "Removal of media streams using relNVITE" 
The expected call flow sequence is: 



Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






1 


















User A initiates a multimedia session with at 
least two streams with User B 




42A 


















User A removes one of the media streams 


J 


43A 
















INVITE 


UE A sends relNVITE to IMS A 




44A 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




45A 


INVITE 


IMS A forwards the relNVITE to IMS B 


f 


46A 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 




47A 


INVITE 


IMS B forwards the relNVITE to UE B 


f 


48A 


100 Trying 


UE_B optionally responds with a 100 Trying 
provisional response 




49A 


















User B is informed that the media stream has 
been removed 


> 




50A 








f 








200 OK 


UE B responds with 200 OK to relNVITE 




51A 


200 OK 


IMS B forwards the 200 OK response to IMS A 




52A 


200 OK 


IMS_A forwards the 200 OK response to UE_A 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






53A 
















ACK 


UE A acknowledges the receipt of 200 OK for 
relNVITE 




54A 


ACK 


IMS A forwards the ACK to IMS B 




55A 


ACK 


IMS B forwards the ACK to UE B 




42B 


















User B removes one of the media streams 






43B 










^ 






INVITE 


UE B sends relNVITE to IMS B 




44B 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 




45B 


INVITE 


IMS B forwards the relNVITE to IMS A 




46B 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




47B 


INVITE 


IMS A forwards the relNVITE to UE A 




48B 


100 Trying 


UE_A optionally responds with a 100 Trying 
provisional response 




49B 


















User A is informed that the media stream has 
been removed 


i 




SOB 
















200 OK 


UE A responds with 200 OK to relNVITE 


^ 


51 B 


200 OK 


IMS A forwards the 200 OK response to IMS B 




52B 


200 OK 


IMS B forwards the 200 OK response to UE B 


^ 


53B 


ACK 


UE B acknowledges the receipt of 200 OK for 
relNVITE 




54B 


ACK 


IMS B forwards ACK to IMS A 




55B 


ACK 


IMS A forwards ACK to UE A 




56 




» 














User A releases the call 


57 
















BYE 


UE A sends BYE to IMS A 




58 


BYE 


IMS A forwards BYE to IMS B 




59 


BYE 


IMS B forwards BYE to UE B 




60 












» 






User B is informed that call has ended 


61 






^ 




^ 






200 OK 


UE B sends 200 OK for BYE 




62 


200 OK 


IMS B forwards the 200 OK response to IMS A 




63 


200 OK 


IMS_A forwards the 200 OK response to UE_A 




64 




^ — 
























User A is informed that call has ended 



4.4.13 Ad-hoc Conferencing service 



4.4.13.1 



Description 



UE A registered on IMS network A, initiates an ad-hoc conf call via CONF AS, connected over ISC interface to IMS 
core A and subsequently invites UE B (registered in IMS B) to join the conf. This Use Case requires support for MRFC 
and MRFP funtiontalities on IMS A. 
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The test sequence when user A initiates an ad-hoc conference call and invites user B to join it, in an interworking 
scenario is: 



Step 


Action 


CF INT CONFCALL 


1 


User A initiates an ad-lioc conference call 


Step 1 


2 


User A is informed the Ad Hoc Conference Call is being set up 


Step 4 


3 


User A is informed the Ad Hoc Conference Call is established 


Step 9 


4 


User A invites user B to join the ad-hoc conference call 


Step 1 2 


5 


User B is informed of incoming invitation from User A to join 
the Conference Call 


Step 27 


6 


User A is notified that User B is being invited to join the call 


Step 33 


7 


User B joins the conference 


Step 41 


8 


User A is notified that User B has joined the conference 


Step 45 


9 


User B leaves the conference 


Step 48 


10 


User B is informed that the conference has ended 


Step 55 


11 


User A is notified that user B has left the conference 


Step 58 



NOTE 1: The proposed test configuration shown in CF_INT_CONF_CALL indicates CONF AS A 

(ASh-MRFCh-MRFP) resources in IMS A, hence the UC refers to UE_A as conference initiator in IMS A 
and UE_B, although the same UC applies alternatively for UE_B as conference initiator in IMS B and 
UE_A as participant in IMS A, which involves a CONF AS B connected to IMS B, not shown in the test 
configuration for simplicity purposes. 

NOTE 2: For the purpose of IMS NNI conformance testing, the proposed test configuration refers to the ISC 

interface as an optional Point of Observation (PO), where the SIP signalling passing through it might be 
observed but not considered part of the conformance testing. 

This proposal is consistent with the most common interoperability scenario where one vendor provides the complete 
solution for the conference service, integrated into a 3"* party IMS core via ISC interface. 



4.4.13.2 



UC 16: SIP Call Flow "Ad-hoc Conference call" 



The expected call flow sequence is: 



Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


A 
S 
A 


1 

IVI 
S 
B 


A 
S 
B 






1 






















User A initiates an ad-hoc conference call 


> 


2 




















INVITE 


UE_A sends INVITE to IMS_A with 
information for all commonly supported 
presence elements 








3 


100 Trying 


ll\/IS_A responds with a 100 Trying 
provisional response 








4 






















User A is informed the Ad Hoc 
Conference Call is being set up 


i 




5 






^ 






V 








INVITE 


IMS A forwards INVITE to IMS A AS 




6 


100 Trying 


IMS_A AS responds with a 100 Trying 
provisional response 




7 


200 OK 


IMS_A AS responds with a 200 OK to 
IMS A, with isfocus parameter. 




8 


200 OK 


IMS A forwards the 200OK response to 
UE A 








9 






















User A is informed the Ad Hoc 
Conference Call is established 


i 




10 










V 










ACK 


UE A acknowledges the receipt of 200 
OK for INVITE 








11 


ACK 


IMS A forwards the ACK to IMS A AS 




12 






















User A invites user B to join the ad-hoc 
conference call 


> 




13 










N 










REFER 


UEA sends REFER message to IMS_A, 
with Refer-To : <UE B uri 
;method=INVITE> 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


A 
S 
A 


1 
IVI 

s 

B 


A 
S 
B 






14 




















REFER 


IMS A forwards the REFER to IMS A AS 


^ 


15 


202 
Accepted 


IMS_A AS responds with a 202 Accepted 


^ 


16 


202 
Accepted 


IMS_A forwards the 202 Accepted 
response to UE A 








17 


NOTIFY 


IMS_A AS sends a NOTIFY to IMS_A to 
inform the conference initiator the 
REFER message is being processed 




18 


NOTIFY 


IMS A forwards the NOTIFY to UE A 






N 


19 


200 OK 


UE A responds with 200 OK to IMS A 








20 


200 OK 


IMS A forwards the 200 OK response to 
IMS A AS 




21 


INVITE 


IMS_A AS sends INVITE to UE_B with 
conference-factory URI (received in the 
REFER message from UE A) 




22 


100 Trying 


IMS_A responds with a 100 Trying 
provisional response 




23 


INVITE 


IMS A forwards the INVITE to IMS B 


^ 




24 


100 Trying 


IMS_B responds with a 100 Trying 
provisional response 






25 


INVITE 


IMS B forwards the INVITE to UE B 






■>. 


26 


100 Trying 


UE_B responds with a 100 Trying 
provisional response 








27 






















User B is informed of incoming invitation 
from User A to join the Conference Call 


d 




28 




















180 Ringing 


UE B sends a 180 ringing to IMS B 




^ 




29 


180 Ringing 


IMS B forwards the 180 ringing to IMS A 






30 


180 Ringing 


IMS A forwards the 180 ringing to IMS A 
AS 




31 












^ 








NOTIFY 


Upon reception of 180 Ringing from 
UE_B, IMS_A AS sends NOTIFY with 
sipfrag: 180 Ringing to inform 
conference initiator that UE_B is being 
invited to join the conference 




32 


NOTIFY 


IMS A forwards the NOTIFY to UE A 








33 




^ 


















User A is notified that User B is being 
invited to join the call 




34 










V 










200 OK 


UE A responds with 200 OK to IMS A 
for NOTIFY 








35 


200 OK 


IMS A forwards the 200 OK response to 
IMS A AS 




36 


200 OK 


UE B responds with 200 OK to IMS B 
for INVITE 








37 


200 OK 


IMS B forwards the 200 OK response to 
IMS A 






38 


200 OK 


IMS A forwards the 200 OK response to 
IMS A AS 




39 








> 














User B joins the conference 


40 






f 














ACK 


UE B acknowledges the 200 OK for 
INVITE 




^ 




41 


ACK 


IMS B forwards the ACK to IMS A 






42 


ACK 


IMS A forwards the ACK to IMS A AS 


^ 


43 


NOTIFY 


AS_A sends NOTIFY to UE_A to inform it 
has successfully joined the conference 




44 


NOTIFY 


IMS A forwards NOTIFY to UE A 








45 




^ 


















User A is alerted that User B has joined 
the conference 




46 










*. 










200 OK 


UE A sends 200 OK response for 
NOTIFY 








47 


200 OK 


IMS A forwards the 200 OK response to 
IMS A AS 







£75/ 



69 



ETSI TS 186 011-2 V2.3.1 (2010-04) 



Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


A 
S 
A 


1 
IVI 

s 

B 


A 
S 
B 






48 






















User B leaves the conference 


> 


49 














V 






BYE 


UE_B sends BYE to IMS_B to leave the 
conference 








50 


BYE 


IMS B forwards the BYE to IMS A 




V 


51 


BYE 


IMS A forwards the BYE to IMS A AS 


^ 


52 


200 OK 


IMS_A AS releases resources for this 
conference caller and sends a 200 OK 
response for BYE 




53 


200 OK 


IMS A forwards the 200 OK response to 
IMS B 






54 


200 OK 


IMS B forwards the 200 OK response to 
UE B 








55 






















User B is informed that the conference 
has ended 


k 




56 






f 














NOTIFY 


AS_A sends NOTIFY to IMS _A to inform 
UE A that UE B has left the conference 




57 


NOTIFY 


IMS A forwards NOTIFY to UE A 








58 






















User A is notified that user B has left the 
conference 


^ 




59 




















200 OK 


UE A sends a 200 OK response for 
NOTIFY 








60 


200 OK 


IMS A forwards the 200 OK response to 
IMS A AS 





























4.4.14 Presence service 



4.4.14.1 Watcher subscription to presence event notification 



4.4.14.1.1 



Description 



UE_B is configured to receive notifications with watcher information. UE_B pubHshes its presence information. UE_A 
subscribes to presence information state changes of UE_B. This test requires the use of appHcation server in IMS_B 
(Presence Server), according to the standard [15]. The call flow path and node configuration for this use case 
corresponds to CF_1NT_AS in case of interworking and CF_ROAM_AS in case of roaming. 

The test sequence typically associated with this use case is as follows (CFW step numbers refer the call flow step 
numbering). 



step 


Action 


CF INT AS 


CF ROAIM AS 


1 


User B publishes presence information 


Stepi 


Slept 


2 


User B is informed of its presence status update 


Step 6 


Steps 


3 


User A subscribes to presence information from User B 


Step? 


Step 9 


4 


User B receives an authorization request from User A to be 
informed of its own presence information 


Step 22 


Step 26 


5 


User B authorizes user A to be informed of its own presence 
information 


Step 23 


Step 27 


6 


User A is informed of User B presence information 


Step 28 


Step 32 
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4.4.14.1.2 UC_17_R: SIP message flow for watcher subscription to presence event 

notification with CF_ROAM_AS 

The expected call flow sequence is: 



Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


A 
S 
A 


1 

M 
S 
B 


A 
S 
B 






1 






















User A publishes presence information 






2 










>. 




>. 






PUBLISH 


UE_B sends PUBLISH with information 
for all commonly supported presence 
elements 


^ 


3 


PUBLISH 


IMS A forwards the PUBLISH to IMS B 


^ 




4 


PUBLISH 


IMS B forwards the PUBLISH to IMS B 
AS (PS) 


^ 


5 


200 OK 


IMS B AS responds with a 200 OK to 
IMS B 




6 


200 OK 


IMS B forwards the 200 OK response 
to IMS A 






7 


200 OK 


IMS A forwards the 200 OK response 
toUE B 




8 






















User B is informed of its presence 
status update 




9 




User A subscribes to presence 
information from User B 


> 




10 




















SUBSCRIBE 


UE_A sends SUBSCRIBE for 
"presence" event to IMS A 








11 


SUBSCRIBE 


IMS A forwards the SUBSCRIBE to 
IMS B 


^ 




12 


SUBSCRIBE 


IMS B forwards the SUBSCRIBE to 
IMS BAS(PS) 


^ 


13 


200 OK 


IMS B AS responds with a 200 OK to 
IMS B 




14 


200 OK 


IMS B forwards the 200 OK response 
to IMS A 






15 












^ 








200 OK 


IMS A forwards the 200 OK response 
toUE A 








16 


NOTIFY 


IMS B AS sends NOTIFY to IMS A 








17 


NOTIFY 


IMS A forwards the NOTIFY to UE A 








18 


200 OK 


UE A responds with a 200 OK to 
IMS A 








19 


200 OK 


IMS A forwards the 200 OK response 
to IMS B AS 






























SUBSCRIPTION triggers the AS to 
send a NOTIFY to UE_B indicating the 
change to the watcher information 
subscriber 


20 










^ 






^ 




NOTIFY 


IMS_B AS sends NOTIFY to IMS_B to 
indicate UE_B the change to the 
watcher information subscriber 




21 


NOTIFY 


IMS B forwards the NOTIFY to IMS A 






22 


NOTIFY 


IMS A forwards the NOTIFY to UE B 




23 


200 OK 


UE B responds with a 200 OK to 
IMS A 




24 


200 OK 


IMS A forwards the 200 OK response 
to IMS B 






25 


200 OK 


IMS B forwards the 200 OK response 
to IMS B AS 




26 






















User B receives an authorization 
request from User A to see its own 
presence information 




27 




User B authorizes user A to be informed 
of its own presence information 










> 












28 












< 








NOTIFY 


IMS B AS sends NOTIFY to IMS A 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 
IVI 

s 

A 


A 
S 
A 


1 

M 
S 
B 


A 
S 
B 






29 




















NOTIFY 


IMS A forwards the NOTIFY to UE B 






>. 


30 


200 OK 


UE A responds with a 200 OK to 
IMS A 








31 


200 OK 


IMS A forwards the 200 OK response 
to IMS B AS 








32 






















User A is informed of user B presence 
information 




33 










^ 










NOTIFY 


IMS_B AS sends NOTIFY to IMS_B to 
indicate UE_B that subscription has 
been authorized 




34 


NOTIFY 


IMS B forwards the NOTIFY to IMS A 






35 


NOTIFY 


IMS A forwards the NOTIFY to UE B 




36 


200 OK 


UE B responds with a 200 OK to 
IMS A 




37 


200 OK 


IMS A forwards the 200 OK response 
to IMS B 






38 


200 OK 


IMS B forwards the 200 OK response 
to IMS B AS 





























4.4.14.1.3 UC_17_I: SIP message flow for watcher subscription to presence event 

notification with CF_INT_AS 

The expected call flow sequence is: 



Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


A 
S 
A 


1 

IVI 

s 

B 


A 
S 
B 






1 






















User B publishes presence information 


> 


2 














V 






PUBLISH 


UE_B sends PUBLISH with information 
for all commonly supported presence 
elements 








3 


PUBLISH 


IMS B forwards the PUBLISH to IMS B 
AS (PS) 




4 


200 OK 


IMS B AS responds with a 200 OK to 
IMS B 




5 


200 OK 


IMS B forwards the 200 OK response to 
UE B 








6 




^ 


















User B is informed of its presence status 
update 




7 




User A subscribes to presence 
information from User B 


^. 






8 










V 




V 


X 




SUBSCRIBE 


UE_A sends SUBSCRIBE for "presence" 
event to IMS A 


^ 






9 


SUBSCRIBE 


IMS A forwards the SUBSCRIBE to 
IMS B 






10 


SUBSCRIBE 


IMS B forwards the SUBSCRIBE to 
IMS BAS(PS) 




11 


200 OK 


IMS B AS responds with a 200 OK to 
IMS B 




12 


200 OK 


IMS B forwards the 200 OK response to 
IMS A 


^ 




13 


200 OK 


IMS A forwards the 200 OK response to 
UE A 


^ 






14 


NOTIFY 


IMS B AS sends NOTIFY to IMS A 








15 


NOTIFY 


IMS A forwards the NOTIFY to UE A 






>. 


16 


200 OK 


UE Aresponds with a200OKto IMS A 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


A 
S 
A 


1 
IVI 

s 

B 


A 
S 
B 






17 




















200 OK 


IMS A forwards the 200 OK response to 
IMS BAS 






























SUBSCRIPTION triggers the AS to send 
a NOTIFY to UEB indicating the change 
to the watcher information subscriber 


18 
















^ 




NOTIFY 


IMS_B AS sends NOTIFY to IMS_B to 
indicate UE_B the change to the watcher 
information subscriber 




19 


NOTIFY 


IMS B forwards the NOTIFY to UE B 






X 


20 


200 OK 


UE B responds with a 200 OK to IMS B 








21 


200 OK 


IMS B forwards the 200 OK response to 
IMS BAS 




22 






















User B receives an authorization request 
from User A to be informed of its own 
presence information 




23 




User B authorizes user A to see its own 
presence information 










> 












24 






f 














NOTIFY 


IMS BAS sends NOTIFY to IMS A 








25 


NOTIFY 


IMS A forwards the NOTIFY to UE A 






■>. 


26 


200 OK 


UE A responds with a 200 OK to IMS A 








27 


200 OK 


IMS A forwards the 200 OK response to 
IMS BAS 








28 






















User A is informed of user B presence 
information 




29 




















NOTIFY 


IMS_B AS sends NOTIFY to IMS_B to 
indicate UE_B that subscription has been 
authorized 


*. 


30 


NOTIFY 


IMS B forwards the NOTIFY to UE B 






V 


31 


200 OK 


UE B responds with a 200 OK to IMS B 








32 


200 OK 


IMS B forwards the 200 OK response to 
IMS BAS 





























4.4.14.2 Watcher subscription to resource list 



4.4.14.2.1 



Description 



UE_B is configured to receive notifications with watcher information. UE_B pubHshes its presence information. User B 
has authorized User A to see its presence information. User A is authorized to use resource lists. UE_A subscribes to 
presence information state changes of a list of users containing UE_B. This test requires the use of application server in 
IMS_B, having the role of Presence Server (PS) and the use of application server in IMS_A, having the role of 
Resource List Server (RLS), according to the standard [15]. The call flow path and node configuration for this use case 
corresponds to CF_INT_AS in case of interworking and CF_ROAM_AS in case of roaming. 

The test sequence typically associated with this use case is as follows (CFW step numbers refer the call flow step 
numbering). 



Step 


Action 


CF INT AS 


CF ROAM AS 


1 


User B publishes presence information 


Step 1 


Step 1 


2 


User B is informed of its presence status update 


Step 6 


Steps 


3 


User A subscribes to resource list containing User B SIP URI 


Step 7 


Step 9 


4 


User A is informed of User B presence information 


Step 30 


Step 32 
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4.4.14.2.2 UC_18_R: SIP message flow for watcher subscription to resource list with 

CF_ROAM_AS 

The expected call flow sequence is: 



Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


A 
S 
A 


1 
IVI 

s 

B 


A 
S 
B 






1 






















User A publishes presence information 






2 










V 




V 






PUBLISH 


UE_B sends PUBLISH with information 
for all commonly supported presence 
elements 


^ 


3 


PUBLISH 


IMS A forwards the PUBLISH to IMS B 


^ 




4 


PUBLISH 


IMS B forwards the PUBLISH to IMS B 
AS (PS) 


^ 


5 


200 OK 


IMS B AS responds with a 200 OK to 
IMS B 




6 


200 OK 


IMS B forwards the 200 OK response to 
IMS A 






7 


200 OK 


IMS A forwards the 200 OK response to 
UE B 




8 








f 














User B is informed of its presence status 
update 




9 




User A subscribes to resource list 


> 


10 




















SUBSCRIBE 


UE_A sends SUBSCRIBE for "presence" 
event to IMS_A indicating support to 
"eventlist" to a resource list SIP URI 








11 


SUBSCRIBE 


IMS A forwards the SUBSCRIBE to 
IMS AAS(RLS) 


























RLS performs authorization checl<s to 
ensure that User A is authorized to use 
resource lists 


12 






^ 






^ 








200 OK 


IMS A AS responds with a 200 OK to 
IMS A 


^ 


13 


200 OK 


IMS A forwards the 200 OK response to 
UE A 


^ 






14 


NOTIFY 


IMS A AS sends NOTIFY to IMS A 




15 


NOTIFY 


IMS A forwards the NOTIFY to UE A 








16 


200 OK 


UE A responds with a 200 OK to IMS A 








17 


200 OK 


IMS A forwards the 200 OK response to 
IMS A AS 


























RLS resolves watcher resource's 
address and subscribes for presence 
event notification for all the presentities 
represented by the resource list SIP URI 


18 












^ 








SUBSCRIBE 


IMS_A AS (RLS) sends SUBSCRIBE for 
"presence" event to IMS A 




19 


SUBSCRIBE 


IMS A forwards the SUBSCRIBE to 
IMS B 






20 


SUBSCRIBE 


IMS B forwards the SUBSCRIBE to 
IMS BAS(PS) 


























PS performs authorization checl<s on the 
originator to ensure it is allowed to watch 
the presentity 


21 




















200 OK 


IMS B AS (PS) responds with a 200 OK 
to IMS B 




22 


200 OK 


IMS B forwards the 200 OK response to 
IMS A 






23 


200 OK 


IMS A forwards the 200 OK response to 
IMS A AS (RLS) 


^ 


24 


NOTIFY 


IMS_B AS sends a NOTIFY to IMS_A 
with the presence information of UE B 








25 


NOTIFY 


IMS A forwards the NOTIFY to IMS A 
AS (RLS) 




>* 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


u 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


A 
S 
A 


1 
IVI 

s 

B 


A 
S 
B 






26 




















200 OK 


IMS A AS responds with a 200 OK to 
IMS A 




27 


200 OK 


IMS A forwards the 200 OK response to 
IMS BAS 






























RLS notifies with presence information 
for all the presentities represented by the 
resource list SIP URI 


28 












^ 








NOTIFY 


IMS A AS sends NOTIFY to IMS A 




29 


NOTIFY 


IMS A forwards the NOTIFY to UE A 








30 


200 OK 


UE A responds with a 200 OK to IMS A 








31 


200 OK 


IMS A forwards the 200 OK response to 
IMS A AS 




32 




i — 
































User A sees user B presence information 



4.4.14.2.3 UC_18_I: SIP message flow for watcher subscription to resource list with 

CF_INT_AS 

The expected call flow sequence is: 



Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


A 
S 
A 


1 
IVI 

s 

B 


A 
S 
B 






1 






















User B publishes presence information 


> 


2 
















»- 




PUBLISH 


UE_B sends PUBLISH with information 
for all commonly supported presence 
elements 








3 


PUBLISH 


IMS B forwards the PUBLISH to IMS B 
AS (PS) 




4 


200 OK 


IMS B AS responds with a 200 OK to 
IMS B 




5 


200 OK 


IMS B forwards the 200 OK response to 
UE B 








6 








^ 














User B is informed of its presence status 
update 




7 




User A subscribes to resource list 


> 


8 




















SUBSCRIBE 


UE_A sends SUBSCRIBE for "presence" 
event to IMS_A indicating support to 
"eventlist" to a resource list SIP URI 








9 


SUBSCRIBE 


IMS A forwards the SUBSCRIBE to 
IMS A AS (RLS) 


























RLS performs authorization checks to 
ensure that User A is authorized to use 
resource lists 


10 












^ 








200 OK 


IMS A AS responds with a 200 OK to 
IMS A 




11 


200 OK 


IMS A forwards the 200 OK response to 
UE A 








12 


NOTIFY 


IMS A AS sends NOTIFY to IMS A 




13 


NOTIFY 


IMS A forwards the NOTIFY to UE A 










14 


200 OK 


UE A responds with a 200 OK to IMS A 








15 


200 OK 


IMS A forwards the 200 OK response to 
IMS A AS 


























RLS resolves watcher resource's 
address and subscribes for presence 
event notification for all the presentities 
represented by the resource list SIP URI 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


A 
S 
A 


1 
IVI 

s 

B 


A 
S 
B 






16 




















SUBSCRIBE 


IMS_A AS (RLS) sends SUBSCRIBE for 
"presence" event to IMS A 




17 


SUBSCRIBE 


IMS A forwards the SUBSCRIBE to 
IMS B 






18 


SUBSCRIBE 


IMS B forwards the SUBSCRIBE to 
IMS BAS(PS) 


























PS performs authorization checl<s on the 
originator to ensure it is allowed to watch 
the presentity 


19 












^ 








200 OK 


IMS B AS (PS) responds with a 200 OK 
to IMS B 




20 


200 OK 


IMS B forwards the 200 OK response to 
IMS A 






21 


200 OK 


IMS A forwards the 200 OK response to 
IMS A AS (RLS) 


^ 


22 


NOTIFY 


IMS_B AS sends a NOTIFY to IMS_A 
with the presence information of UE B 








23 


NOTIFY 


IMS A forwards the NOTIFY to IMS A 
AS (RLS) 




24 


200 OK 


IMS A AS responds with a 200 OK to 
IMS A 




25 




















200 OK 


IMS A forwards the 200 OK response to 
IMS BAS 






























RLS notifies with presence information 
for all the presentities represented by the 
resource list SIP URI 


26 












^ 








NOTIFY 


IMS A AS sends NOTIFY to IMS A 




27 


NOTIFY 


IMS A forwards the NOTIFY to UE A 






V 


28 


200 OK 


UE A responds with a 200 OK to IMS A 








29 


200 OK 


IMS A forwards the 200 OK response to 
IMS A AS 




30 




^ — 
































User A sees user B presence information 



4.4.15 IPTV service 



4.4.1 5.1 Broadcast (BC) Session 



4.4.15.1.1 



Description 



UE_A starts a session initiation procedure to join a multicast channeL This test requires the use of application server as 
specified in [14]. The call flow path and node configuration for this use case corresponds to CF_IPTV. 



4.4.15.1.2 



DC 19: BC session 



The test sequence typically associated with this use case is as follows (CFW step numbers refer the call flow step 
numbering). 



Step 


Action 


CF IPTV 


1 


User A initiates a BC session 


Stepi 


2 


User A receives the broadcast content 


Step 8 


3 


User A terminates the session 


Step 9 


4 


User A is informed that session is terminated 


Step 14 



The expected call flow sequence is: 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 
IVI 

s 

A 


A 
S 
A 


1 

M 
S 
B 


A 
S 
B 






1 




> 


















User A initiates a BC session 


2 












*. 








INVITE 


UE A sends INVITE to IMS A 


^ 






3 


INVITE 


IMS A forwards the INVITE to AS A 




4 


200 OK 


AS A responds with 200 OK 




5 


200 OK 


IMS A forwards the 200 OK response to 
UE A 






>. 


6 


ACK 


UE A acknowledges the receipt of 200 
OK for INVITE 








7 


ACK 


IMS A forwards the ACK to AS A 




8 
9 




i 

> 


















User A receives the broadcast content 
User A terminates the session 


10 












*. 








BYE 


UE A sends BYE to IMS A 








11 


BYE 


IMS A forwards the BYE to AS A 




12 


200 OK 


AS A responds with 200 OK 




13 






^ 














200 OK 


IMS A forwards the 200 OK response to 
UE A 








14 






















User A is informed that session is 
terminated 





























4.4.15.2 Content on Demand (CoD) Session 



4.4.15.2.1 



Description 



UE_A starts a session initiation procedure for a streaming session of a selected content. The document [14] specifies 
two methods for establishing a streaming session (called RTSP Method 1 and 2). This tests requires the use of 
application server, playing the roles of Service control Function (SCF) and Media Function (MF), as specified in [14]. 
The call flow path and node configuration for this use case corresponds to CF_IPTV. 

The test sequence typically associated with this use case is as follows (CFW step numbers refer the call flow step 
numbering). 



Step 


Action 


CF IPTV 
RTSP Method 1 


CF IPTV 
RTSP Metliod 2 


1 


User A initiates a CoD session (content selection) 


Stepi 


Stepi 


2 


User A starts receiving the streaming content 


Step 26 


Step 14 


3 


User A terminates the session 


Step 27 


Step 1 5 


4 


User A is informed that session is terminated 


Step 36 


Step 24 



£75/ 



77 



ETSI TS 186 011-2 V2.3.1 (2010-04) 



4.4.1 5.2.2 UC_20: CoD session establishing content control channel and content delivery 

channels separately (RTSP Method 1) 

The expected call flow sequence is: 



Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 
IVI 

s 

A 


A 

s 

A 


1 

M 
S 
B 


A 
S 
B 






1 






















User A initiates a CoD session (content 
selection) 




2 










V 










INVITE 


UE A sends a INVITE to IMS A 








3 


INVITE 


IMS A forwards the INVITE to AS A 
(SCF) 


f 


4 


INVITE 


AS A forwards the INVITE to IMS A 


V 


5 


INVITE 


IMS A forwards the INVITE to AS A 
(MF) 




6 


200 OK 


AS A (MF) responds with 200 OK 


^ 


7 


200 OK 


IMS A forwards the 200 OK response to 
AS A (SCF) 


f 


8 


200 OK 


AS A forwards the 200 OK response to 
IMS A 


^ 


9 


200 OK 


IMS A forwards the 200 OK response to 
UE A 








10 


ACK 


UE A acknowledges the receipt of 200 
OK for INVITE 








11 


ACK 


IMS A forwards the ACK to AS A (SCF) 




12 


ACK 


AS A forwards the ACK to IMS A 


V 


13 


ACK 


IMS A forwards the ACK to AS A (MF) 


























UE A sets up RTSP with AS A (MF) 


14 










V 


V 








INVITE 


UE_A sends relNVITE message 
indicating media attribute " a=recvonly " 


f 






15 


INVITE 


IMS A forwards the relNVITE to AS A 
(SCF) 




16 


INVITE 


AS A forwards the relNVITE to IMS A 


V 


17 


INVITE 


IMS A forwards the relNVITE to AS A 
(MF) 




18 


200 OK 


AS A (MF) responds with 200 OK 




19 


200 OK 


IMS A forwards the 200 OK response to 
AS A (SCF) 


f 


20 


200 OK 


IMS B forwards the 200 OK response to 
IMS A 




21 


200 OK 


IMS A forwards the 200 OK response to 
UE A 






V 


22 


ACK 


UE A acknowledges the receipt of 200 
OK for relNVITE 








23 


ACK 


IMS A forwards the ACK to AS A (SCF) 


f 


24 


ACK 


AS A forwards the ACK to IMS A 


V 


25 


ACK 


IMS A forwards the ACK to AS A (MF) 




26 






















User A starts receiving the streaming 
content 


i 










> 










27 




User A terminates the session 


28 










V 


V 








BYE 


UE A sends a BYE to IMS A 








29 


BYE 


IMS A forwards the BYE to AS A (SCF) 




30 


BYE 


AS A forwards the BYE to IMS A 


V 


31 


BYE 


IMS A forwards the BYE to AS A (MF) 




32 


200 OK 


AS A (MF) responds with 200 OK 


V 


33 


200 OK 


IMS A forwards the 200 OK response to 
AS A (SCF) 


f 


34 


200 OK 


IMS B forwards the 200 OK response to 
IMS A 




35 


200 OK 


IMS A forwards the 200 OK response to 
UE A 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 
IVI 

s 

A 


A 
S 
A 


1 

M 
S 
B 


A 
S 
B 






36 






















User A is informed tliat session is 
terminated 

































4.4.1 5.2.3 UC_21 : CoD session establishing content control channel and content delivery 

channels separately using RTSP Method 2 

The expected call flow sequence is: 



Step 


Direction 


Message 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

IVI 

s 

A 


A 
S 
A 


1 

M 
S 
B 


A 
S 
B 






1 






















User A initiates a CoD session (content 
selection) 


> 




2 










■N. 










INVITE 


UE A sends a INVITE to IMS A 


^ 






3 


INVITE 


IMS A forwards the INVITE to AS A 
(SCF) 




4 


INVITE 


AS A forwards the INVITE to IMS A 


V 


5 


INVITE 


IMS A forwards the INVITE to AS A 
(MF) 




6 


200 OK 


AS A (MF) responds with 200 OK 


V 


7 


200 OK 


IMS A forwards the 200 OK response to 
AS A (SCF) 


f 


8 


200 OK 


AS A forwards the 200 OK response to 
IMS A 




9 


200 OK 


IMS A forwards the 200 OK response to 
UE A 








10 


ACK 


UE A acknowledges the receipt of 200 
OK for INVITE 








11 


ACK 


IMS A forwards the ACK to AS A (SCF) 




12 


ACK 


AS A forwards the ACK to IMS A 


N 


13 


ACK 


IMS A forwards the ACK to AS A (MF) 




14 




> 


















UEA starts receiving the streaming 
content 


15 




User A terminates the session 


16 












V 








BYE 


UE A sends a BYE to IMS A 








17 


BYE 


IMS A forwards the BYE to AS A (SCF) 




18 


BYE 


AS A forwards the BYE to IMS A 


V 


19 


BYE 


IMS A forwards the BYE to AS A (MF) 




20 


200 OK 


AS A (MF) responds with 200 OK 


V 


21 


200 OK 


IMS A forwards the 200 OK response to 
AS A (SCF) 


f 


22 


200 OK 


IMS B forwards the 200 OK response to 
IMS A 




23 


200 OK 


IMS A forwards the 200 OK response to 
UE A 








24 




^ 


















User A is informed that session is 
terminated 





























4.4.1 5.3 Request for Network PVR offline capture 



4.4.15.3.1 



Description 



UE_A starts a N-PVR offline capture procedure to record a live programme that has not started yet. Once the capture 
has finished, UE_A establishes a CoD session to receive the streaming content using RTSP Method 1 or RTSP 
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Method 2. The scope of this Use Case is to describe the capturing procedure, since CoD session is already described in 
the previous section. This test requires the use of an application server, as specified in [14]. The call flow path and node 
configuration for this use case corresponds to CF_IPTV. 



4.4.15.3.2 



UC_22: Request for Network PVR offline capture. 



The test sequence typically associated with this use case is as follows (CFW step numbers refer the call flow step 
numbering). 



Step 


Action 


CF INT IPTV 


1 


User A requests to record a live programme that has not started yet 


Stepi 


2 


User A is informed that recording has started 


Step 6 



The expected call flow sequence is: 



Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 
IVI 

s 

A 


A 
S 
A 


1 

M 
S 
B 


A 
S 
B 






1 






















User a requests to record a live 
programme that has not started yet 


> 




2 










V 










MESSAGE 


UE A sends a MESSAGE to IMS A 








3 


MESSAGE 


IMS A forwards the MESSAGE to AS 


A 


f 


4 


200 OK 


AS A responds with 200 OK 




5 


200 OK 


IMS A forwards the 200 OK response 
UE A 


to 








6 




f 


















User A is informed that recording has 
started 

























4.5 Test Descriptions 



This clause introduces interoperability test descriptions (TDs) which realize one or more IMS NNI test purposes of 
TS 186 011-1 [2]. 

Each TD is defined on the basis of one of the generic use cases forms presented in the previous clause. Each test 
sequence step in a TD includes also a reference to a specific call flow step of the generic use case. Call flow steps which 
are associated with the test body are repeated after each TD and include any modifications necessary to adapt the 
generic use case. In the adapted call flow steps that are associated with user interactions are shown shaded and steps 
which have pass criteria are associated with are shown in bold. 

Note that the expected test sequence may only show the Call Flow that affects the test. 

In the tabulations which follow, all references are to TS 124 229 [1]. 
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4.5.1 General Capabilities 



4.5.1.1 



SIP messages longer than 1 500 bytes 



Interoperability Test Description 



Identifier: 



TD_IMS_MESS_0001 

IMS network shall support SIP messages greater than 1 500 bytes. 
CF INT CALL 



Summary: 



Configuration: 



BUT 



IMS B 



References 



Test Purpose 



Specification Reference 



IP IMS 4002 1 



TS 124 229 [1], clause 4.2A 111 



Use Case ref. 



UC 05 I 



Pre-test 
conditions: 



Test Sequence: 



Conformance 
Criteria: 



HSS of IMS_A and of IMS B is configured according to table 1 

UEA and UEB have IP bearers established to their respective IMS networks as 

per clause 4.2.1 

UE_A and IMS_A configured to use TCP for transport 

UE_A is registered in IMS_A using any user identity 

UE_B is registered user of IMS_B using any user identity 



Step 



User A sends message to User B with at least 1 500 characters 



Verify that user B receives message from user A 



Check 




verity 



TP_IMS_4002_01 in CFW step 3 (MESSAGE) 
ensure that { 
when { UE_A sends a MESSAGE to UE_B 

containing a Message_Body greater than 1 300 bytes } 
then { IMS_B receives the l\/IESSAGE 

containing the Message_Body greater than 1 300 bytes } 
}_ 



Step 


Direction 


Message 


Comment 


-| 


U 
s 
e 
r 
A 


U 

E 
A 

^1 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 

s 
e 
r 
B 




1 Iqpt a cipnHc; an in^tpnt mPQQanp tn iic;pr R 


2 






V 










MESSAGE 


UE A sends MESSAGE to IMS A 




3 


MESSAGE 


IMS_A sends MESSAGE to IMS_B with via 
header indicating TCP 




4 


MESSAGE 


IMS B sends MESSAGE to UE B 




6 










^ 


? 




200 OK 


UE B sends 200 OK to IMS B 




7 


200 OK 


IMS B sends 200 OK to IMS A 




8 
9 


200 OK 


IMS A sends 200 OK to UE A 

Optional: User A is presented a delivery report 
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4.5.2 Registration and De-registration 



4.5.2.1 



First time registration in a visited IMS network 



Interoperability Test Description | 


Identifier: 


ID IMS REG 0001 


Summary: 


First time registration in a visited IMS networl<. 


Configuration: 


CF ROAM REG 


SUT 


IMS A and IMS B 


References 


Test Purpose 


Specification Reference 


IP IMS 5011 01 


TS 124 229 [1], clause 5.2.2 112 


IP IMS 5011 02 


TS 124 229 [1], clause 5.2.2 12 


IP IMS 5044 01 


TS 124 229 [1], clause 5.2.3 HI 


IP IMS 5089 01 


TS 124 229 [1], clause 5.4.1.2.1 116 


IP IMS 5092 01 


TS 124 229 [1], clause 5.4.1.2.2 HI 


IP IMS 5096 01 


TS 124 229 [1], clause 5.4.2.1.1 HI 


Use Case ref.: 


UC 01 R 1 




Pre-test 
conditions: 


• HSS of IMS_B is configured according to table 1 

• UE_B IP bearers establislied to IMS_A as per clause 4.2.1 

• UE_B not registered in IMS_B 

• IMS_A witfiin the trust domain of IMS_B 

• UE B is configured to use AKA authentication 




Test Sequence: 


Step 




1 


User B registers in IMS B using any valid user identity 


2 


Verify that UE_B shows successful registration 


Conformance 
Criteria: 


Clieck 




1 


TP_IMS_501 1_01 in CFW step 3 (REGISTER): 
ensure that { 
when { UE_B sends an unprotected REGISTER to IMS_A 

containing a Security-Client header} 
then { IMS_A sends the REGISTER to IMS_B 
containing a Path header 

containing P-CSCF_SIP_URI of IMS_A and 
containing a Require_header 

containing a path_option_tag and 
containing a P-Charging-Vector_header 
containing an icid_parameter and 
containing an orig-ioi_parameter and 
not containing a term-ioi_parameter and 
containing a Authorization_header 
containing an integrity-protected_parameter 
indicating no 
not containing a Security-Verifyheader and 
not containing a Security-Client_header and 
containing a P-Visited-Networl<-ID_header 
indicating "the visited network at the home network"} 

} 
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Interoperability Test Description 



TP_IMS_501 1_02 in CFW step 7 (REGISTER): 
ensure that { 
when { UE_B sends a protected REGISTER to IMS_A 

containing a Security-Client_header } 
then { IMS_A sends the REGISTER to IMS_B 
containing a Path_header 

containing P-CSCF_SIP_URI of IMS_A and 
containing a Require_header 

containing a path_option_tag and 
containing a P-Charging-Vector_header 
containing an icid_parameter and 
containing an orig-ioi_parameter 

indicating IMS_A and 
not containing a term-ioi_parameter and 
containing a Authorization_header 
containing an integrity-protected_parameter 
indicating yes 
not containing a Security-Verify _header and 
not containing a Security-Client_header and 
containing a P-Visited-Network-ID_header 
indicating "the visited network at the home network"} 
1 



TP_IMS_5044_01 in CFW step 10 (SUBSCRIBE): 
ensure that { 
when { IMS_A receives a 200_response from IMS_B 

} 
then { IMS_A sends a SUBSCRIBE to IMS_B 
containing a Request_URI 
indicating "the resource to which the P-CSCF wants 
to subscribe to" and 
containing a From_header 
indicating P-CSCF_SIP_URI of IMS_A and 
containing a To_header 

indicating the defauit_public_user_identity of UEB and 
containing an Event_header 
indicating the reg_event_package and 
containing an Expires_header 
set to "a value greater than the one in the Expires_header 
of the 200_response" and 
containing a P-Asserted-ldentity_header 

set to the P-CSCF_SIP_URI of IMS_A and 
containing a P-Charging-Vector_header 
containing an icid_parameter } 
I 



TP_II\/IS_5089_01 in CFW step 4 (401 Unauthorized): 
ensure that { 
when { UE_B sends an initial REGISTER to IMS_B and 
IMS_A sends the REGISTER to IMS_B 
containing an Authorization_header 

containing an integrity-protected_parameter indicating no } 
then { IMS_B sends a 401_response to IMS_A 
containing an WWW-Authenticate_header 
containing a realm_parameter 

indicating the operatorjdentifier of IMS_B and 
containing a nonce_parameter 
(containing a RANDparameter and 
containing an AUTN_parameter) and 
containing an algorithm_parameter 

indicating AKAv1-MD5 and 
containing an ik_parameter and 
containing a ck_parameter } 
} 
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Interoperability Test Description 



TP_IMS_5092_01 in CFW step 8 (200 Ok): 
ensure that { 
when { UE_B sends a protected REGISTER to IMS_B and 
IMS_A sends the REGISTER to IMS_B 
containing an Authorization_header 

containing an integrity-protected_parameter indicating yes } 
then { IMS_B sends 200_response to IMS_A 

containing the same Path_header as in the protected REGISTER 
and 

containing a P-Associated-URI_header 
containing all registered_public_identities and "its 
associated set of implicitly registered public user identities " 
indicating (first the default_public_user_identity and 
no barred_public_user_identities) and 
containing a Service-Route_header 

indicating the S-CSCF_SIP_URI of IMS_B and 
containing a P-Charging-Vector_header 
including a term-ioi_parameter 
indicating operatorjdentifier of IMS_B and 
containing a Contact_header 
indicating "all contact addresses" 

for the default_public_user_identity of UEB } 
1 



TP_IMS_5096_01 in CFW step 16 (200 0I<): 
ensure that { 
when { 

IMS_B receives a SUBSCRIBE from UE_B via IMS_A 
containing an Event_header indicating the reg_event_package } 
then{ 

mS_B sends a 2XX_response to UE_B 
containing an Expires_header 

indicating "the same or lower expiry time than 
specified in the initial SUBSCRIBE" } 
1 



Step 


Direction 


Message 


Comment 








U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


1 

M 
S 
B 






1 














User B registers in IMS B 


^ 


2 












REGISTER 


UE B sends a REGISTER to IMS A 


f 


3 


REGISTER 


IMS A forwards the REGISTER to IMS B 


^ 


4 


401 Unauthorized 


IMS B responds with 401 Unauthorized to 
IMS A 


*. 


5 


401 Unauthorized 


IMS A forwards the 401 Unauthorized to UE B 




6 


REGISTER 


UE_B sends the same REGISTER containing 
authentication challenge response to IMS A 


f 


7 


REGISTER 


IMS A forwards the REGISTER to IMS B 




8 


200 OK 


IMS B responds with 200 OK 


V 


9 


200 OK 


IMS A forwards the 200 OK response to UE B 




10 


SUBSCRIBE 


IMS A sends a SUBSCRIBE to IMS B 


^ 


11 


200 OK 

or 202 Accepted 


IMS_B responds with a 200 OK or 202 
Accepted 




12 


NOTIFY 


IMS_B sends a NOTIFY to IMS_A, containing 
UE B's registration status 




13 


200 OK 


IMS A responds to the NOTIFY with a 200 OK 


V 


14 


SUBSCRIBE 


UE_B sends a SUBSCRIBE (reg event 
package) to IMS A 




15 


SUBSCRIBE 


IMS A forwards the SUBSCRIBE request to 
IMS B 




16 


200 OK or 

202 Accepted 


IMS_B responds with 200 OK or 202 Accepted 
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Step 


Direction 


IVIessage 


Comment 








U 
s 
e 
r 
B 


U 

E 
B 


\ 

lUI 
S 
A 


1 
lUI 

s 

B 






17 












200 OK or 
202 Accepted 


IMS_A forwards the 200 OK response to UE_B 
or 202 Accepted 




18 




f 






NOTIFY 


IMS_B sends a NOTIFY to IMS_A, containing 
UE B's registration status 




19 


NOTIFY 


IMS A forwards the NOTIFY to UE B 




20 


200 OK 


UE B responds to the NOTIFY with a 200 OK 




21 
22 


200 OK 


IMS A forwards the 200 OK to IMS B 

User B is informed about successful registration 








«— 











4.5.2.2 



No response from first entry point on REGISTER without topology hiding 



Interoperability Test Description 


Identifier: 


TD IMS REG 0002 


Summary: 


IMS network chooses a second entry point to the home network of a user that 
requested registration, if the first entry point does not answer, without topology hiding. 


Configuration: 


CF ROAM REG 


SUT 


IMS A 


References 


Test Purpose 


Specification Reference 


TP IMS 5203 01 


TS 124 229 [1], clause 5.2.2 1126 


TP IMS 5092 01 


TS 1 24 229 [1], clause 5.4.1 .2.2 HI 


Use Case ref.: 


UC 01 R 1 


Pre-test 
conditions: 


• HSS of IMS_B is configured according to table 1 

• UE_B IP bearers established to IMS_A as per clause 4.2.1 

• IMS_A configured with multiple entry points for IMS_B 

• IMS_A not configured for topology hiding 

• First entry point determined by the IMS A pointing to a non-existing component 
in IMS B 


I 


1 


Test Sequence: 


Step 




1 


User B registers in IMS B using any user identity 


2 


Verify that UE B shows successful registration 






Conformance 
Criteria: 


Checl< 




1 


TP_IMS_5203_01 in CFW step 4 (REGISTER): [l-CSCF] 
ensure that { 

when { IMS_A receives no response from IMS_B } 

then { IMS A sends the REGISTER to another entry point of IMS Bj 

} 
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Interoperability Test Description 



TP_IMS_5092_01 in CFW step 9 (200 Ok): 
ensure that { 
when { UE_B sends a protected REGISTER to IMS_B and 
IMS_A sends the REGISTER to IMS_B 
containing an Authorization_header 

containing an integrity-protectedjDarameter indicating yes } 
then { IIVIS_B sends 200_response to IIVIS_A 

containing the same Path_header as in the protected REGISTER 
and 

containing a P-Associated-URI_header 
containing all registered_public_identities and "its 
associated set of implicitly registered public user identities" 
indicating (first the default_public_user_identity and 
no barred_public_user_identities) and 
containing a Service-Route_header 

indicating the S-GSGF_SIP_URI of IMS_B and 
containing a P-Charging-Vector_header 
including a term-ioi_parameter 
indicating operatorjdentifier of IUT_ and 
containing a Contact_header 
indicating "all contact addresses" 
for the default_public_user_identity of UE_B } 



Step 


Direction 


IVIessage 


Comment 








U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


1 

M 
S 
B 






1 














User B activates the UE in the home network 


^ 


2 










REGISTER 


UE B sends a REGISTER to IMS A 




3 


REGISTER 


IMS_A forwards the REGISTER to first entry 
point defined for IMS B 


















No response from IMS B 


4 












REGISTER 


ll\/IS_A sends a REGISTER to another entry 
point defined for IMS B 


^ 


5 


401 Unauthorized 


IMS B responds with 401 Unauthorized to 
IMS A 




6 


401 Unauthorized 


IMS A forwards the 401 Unauthorized to UE B 




7 


REGISTER 


UE_B sends the same REGISTER containing 
authentication challenge response to IMS A 




8 


REGISTER 


IMS A forwards the REGISTER to IMS B 




9 


200 OK 


IMS B responds with 200 OK 




10 


200 OK 


IMS A forwards the 200 OK response to UE B 




11 


SUBSCRIBE 


IMS A sends a SUBSCRIBE to IMS B 




12 


200 OK or 202 
Accepted 


IMS_B responds with a 200 OK or 202 
Accepted 




13 


NOTIFY 


IMS_B sends a NOTIFY to IMS_A, containing 
UE B's registration status 




14 


200 OK 


IMS A responds to the NOTIFY with a 200 OK 




15 


SUBSCRIBE 


UE_B sends a SUBSCRIBE (reg event 
package) to IMS A 




16 


SUBSCRIBE 


IMS A forwards the SUBSCRIBE request to 
IMS B 




17 


200 OK or 
202 Accepted 


IMS_B responds to the SUBSCRIBE with a 200 
OK or 202 Accepted 


^ 


18 


200 OK or 
202 Accepted 


IMS_A forwards the 200 OK or 202 Accepted 
response to UE B 


f 


19 


NOTIFY 


IMS_B sends a NOTIFY to IMS_A, containing 
UE B's registration status 




20 


NOTIFY 


IMS A forwards the NOTIFY to UE B 




21 


200 OK 


UE B responds to the NOTIFY with a 200 OK 




22 


200 OK 


IMS A forwards the 200 OK to IMS B 




23 














User B is informed about successful registration 








i 
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4.5.2.3 



No response from first entry point on REGISTER with topology hiding 



Interoperability Test Description | 


Identifier: 


ID IMS REG 0002H 


Summary: 


IMS network chooses a second entry point to the home network of a user that 
requested registration, if the first entry point does not answer. With topology hiding. 


Configuration: 


OF ROAM REG 


SUT 


IMS A 


References 


Test Purpose 


Specification Reference 


IP IMS 5402 01 


TS 124 22911], clause 5.10.2.1 V 


Use Case ref.: 


UC 01 R 1 


1 -^^ 1 


Pre-test 
conditions: 


• HSS of IMS_B is configured according to table 1 

• UE_B IP bearers established to IMS_A as per clause 4.2.1 

• IMS_A configured with multiple entry points for IMS_B 

• IMS_A configured for topology hiding 

• First entry point determined by the IMS A pointing to a non-existing component 
in IMS B 


L J 


Test Sequence: 


Step 




1 


User B registers in IMS B using any user identity 


2 


Verify that UE B shows successful registration 


Conformance 
Criteria: 


Checl< 


1 


1 


TP_IMS_5402_01 in CFW step 4 (REGISTER): [IBCF] 
ensure that { 
when { UE_B sends a REGISTER to IMS_A and 
IMS_B does not send a response to IMS_A } 
then { IMS_A sends the original REGISTER to 

another entry point of IMS Bj 
} 



Step 


Direction 


Message 


Comment 








U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


1 

M 
S 
B 






1 




^ 










User B activates the UE in the home network 


2 






>. 






REGISTER 


UE B sends a REGISTER to IMS A 




3 


REGISTER 


iMS_A forwards the REGISTER to first entry 
point defined for IMS B 


















No response from IMS B 


4 






^ 


V 




REGISTER 


ll\/IS_A sends a REGISTER to anotiier entry 
point defined for IMS_B 




5 


401 Unauthorized 


IMS B responds with 401 Unauthorized to 
IMS A 




6 


401 Unauthorized 


IMS A forwards the 401 Unauthorized to UE B 


>. 


7 


REGISTER 


UE_B sends the same REGISTER containing 
authentication challenge response to IMS A 




8 


REGISTER 


IMS A forwards the REGISTER to IMS B 


y 


9 


200 OK 


IMS B responds with 200 OK 




10 


200 OK 


IMS A forwards the 200 OK response to UE B 




11 


SUBSCRIBE 


IMS A sends a SUBSCRIBE to IMS B 




12 












200 OK or 
202 Accepted 


IMS_B responds with a 200 OK or 202 
Accepted 


^ 


13 


NOTIFY 


IMS_B sends a NOTIFY to IMS_A, containing 
UE B's registration status 




14 


200 OK 


IMS A responds to the NOTIFY with a 200 OK 


N. 


15 


SUBSCRIBE 


UE_B sends a SUBSCRIBE (reg event 
package) to IMS A 




16 


SUBSCRIBE 


IMS A forwards the SUBSCRIBE request to 
IMS B 
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Step 


Direction 


IVIessage 


Comment 








U 
s 
e 
r 
B 


U 

E 
B 


1 

lUI 
S 
A 


1 
lUI 

s 

B 






17 












200 OK or 
202 Accepted 


IMS_B responds to the SUBSCRIBE with a 200 
OK or 202 Accepted 


^ 


18 


200 OK or 
202 Accepted 


IMS_A forwards the 200 OK or 202 Accepted 
response to UE B 


f 


19 


NOTIFY 


IMS_B sends a NOTIFY to IMS_A, containing 
UE B's registration status 




20 


NOTIFY 


IMS A forwards the NOTIFY to UE B 




21 


200 OK 


UE B responds to the NOTIFY with a 200 OK 




22 


200 OK 


IIVIS A forwards the 200 OK to IIVIS B 




23 




i 










User B is informed about successful registration 



4.5.2.4 403 response to REGISTER from an un-trusted domain without topology 

hiding 



Interoperability Test Description 



Identifier: 



TD IIVIS REG 0003 



Summary: 



IMS network sends 403 response when attempting registration from a different trust 
domain without topology hiding. 



Configuration: 



CF ROAM REG 



SUT 



IMS B 



References 



Test Purpose 



TP IMS 5129 01 



Specification Reference 



TS 124 229 [1], clause 5.3.1.2 HI 



Use Case ref.: 



UC 01 R 



Pre-test 
conditions: 



HSS of IMS_B is configured according to table 1 

UE_B IP bearers established to IMS_A as per clause 4.2.1 

IMS_B not configured for topology hiding 

IMS A and IMS B are in different trust domains 



Test Sequence: 



Step 



User B registers in IMS B using any user identity 



Verify that UEB shows unsuccessful registration 



Conformance 
Criteria: 



Checl< 



1 



TP_IMS_5129_01 in CFW step 3 (REGISTER) [l-CSCF]: 
ensure that { 

when { UE_B sends a valid initial REGISTER to IMS_A 
and IMS_B receives the REGISTER from IMS_A} 

then { IMS_B sends a 403_response to IMS_A } 
1 



Step 


Direction 


IVIessage 


Comment 








U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


1 

M 
S 
B 






1 




^ 










User B activates the UE in a visited network 


2 












REGISTER 


UE B sends a REGISTER to IMS A 


i 


3 


REGISTER 


IMS A forwards the REGISTER to IMS B 


f 


4 


403 Forbidden 


IMS B responds witfi 403 Forbidden to 
IMS A 




5 


403 Forbidden 


IMS A forwards the 403 Forbidden to UE B 


6 




^ 










User B is informed about the registration is 
rejected 
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4.5.2.5 



403 response to REGISTER from an un-trusted domain with topology hiding 



Interoperability Test Description 


Identifier: 


TD IMS REG 0003H 


Summary: 


IMS network sends 403 response when attempting registration from a different trust 
domain witli topology hiding. 


Configuration: 


CF ROAM REG 


BUT 


IMS B 


References 


Test Purpose 


Specification Reference 


IP IMS 5411 01 


TS 124 229 [1], clause 5.10.3.1 HI 


Use Case ref.: 


UC 01 R 


Pre-test 
conditions: 


• HSS of IMS_B is configured according to table 1 

• UE_B IP bearers established to IMS_A as per clause 4.2.1 

• IMS_B configured for topology hiding 

• IMS A and IMS B are in different trust domains 


1 


Test Sequence: 


Step 




1 


User B registers in IMS B using any user identity 


2 


Verify that UEB shows unsuccessful registration 


1 




1 


Conformance 
Criteria: 


Check 




1 


TP_IMS_541 1_01 in CFW step 3 (REGISTER) [IBGF]: 
ensure that { 

when { UE B sends a valid REGISTER to IMS A and 
IMS_B sends the REGISTER to IMS_B } 

then { IMS B sends a 403 response to IMS A } 
} 



Step 


Direction 


Message 


Comment 








U 
s 
e 
r 

B 

1 


U 

E 
B 


1 

lUI 
S 
A 

1 


1 

M 
S 
B 

1 






1 
2 




^ 




V 




REGISTER 


User B activates the UE in a visited network 
UE B sends a REGISTER to IMS A 


^ 


3 


REGISTER 


IMS A forwards the REGISTER to IMS B 




4 


403 Forbidden 


IMS B responds with 403 Forbidden to 
IMS A 




5 


403 Forbidden 


IMS A forwards the 403 Forbidden to UE B 




6 














User B is informed about the registration is 
rejected 



















4.5.2.6 

Void. 



Network initiated re-registration with new contact information 



4.5.2.7 



Network initiated deregistration by the S-CSCF 



Interoperability Test Description 


Identifier: 


TD IMS REG 0005 


Summary: 


IMS network can initiate user de-registration, e.g. when a user runs out of credit. 


Configuration: 


CF ROAM REG 


SUT 


IMS B 


References 


Test Purpose 


Specification Reference 


TP IMS 5093 01 


TS 124 229 [1], clause 5.4.1.5 116 


Use Case ref.: 


UC 01 R 1 


r 


1 


Pre-test 
conditions: 


• HSS of IMS_B is configured according to table 1 

• UE_B IP bearers established to IMS_A as per clause 4.2.1 

• UE B registered in IMS B via IMS A using any user identity 
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Interoperability Test Description 



IMS A within the trust domain of IIVIS B 



Test Sequence: 



Step 



ll\/IS_B is triggered manually to de-register user B 



Verify that UE_B shows successful de-registration 



Conformance 
Criteria: 



Check 



1 



TP_IMS_5093_01 in CFW step 23 and 27 
ensure that { 
when { IMS_B receives a network_originated_deregistration_event } 
then{ 
IMS_B sends a NOTIFY to IMS_A 
containing a Request_URI 

indicating UEB and 
containing an Event_header 

indicating the reg_event_paci<age and 
containing a Route_header 

indicating the originai Route_header from SUBSCRIBE and 
containing a Message_Body 
containing for each registered_public_identity of UEB 
a registration_element 
(containing an aor_attribute 

indicating registered_public_identity of UE_B and 
containing a state_attribute 
indicating terminated and 
containing a contact_subelement 
(containing an event_attribute 

indicating deactivated or rejected 
containing a state_attribute indicating terminated and 
containing an URI_subeiement 
indicating the contact_address of UEB) and 
IMS_B sends a NOTIFY to IMS_A 
containing a Request_URI 

indicating P-CSCF_SIP_URI of IMS_A and 
containing an Event_header 

indicating the reg_event_package and 
containing a Route_header 

indicating the original Route_header from SUBSCRIBE and 
containing a Message_Body 
containing for each registeredjDublicJdentity of UEA 
a registration_element 
(containing an aorattribute 

indicating registered_public_identity of UEA and 
containing a state_attribute 
indicating terminated and 
containing a contact_subelement 
(containing an event_attribute 

indicating deactivated or rejected and 
containing a state_attribute indicating terminated and 
containing an URI_subelement 
indicating the contact_address of UE_A) } 
I 



Step 





Direction 






U 


U 


1 




s 


E 


M 




e 


B 


S 




r 




A 




B 







Message 



Comment 



23 



24 



25 



26 



I 

M 
S 
B 



< 

« 

^ 

^ 



IMS_B is triggered to de-register user B 



NOTIFY 



IMS_B sends a NOTIFY to IMS_A, containing 
UE_B's de-registration 



NOTIFY 



IMS_B sends a NOTIFY to UE_B, containing 
UE_B's de-registration 



200 OK 



UE_B responds to the NOTIFY with a 200 OK 



200 OK 



IMS A forwards the 200 OK to IMS B 
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Step 


Direction 


IVIessage 


Comment 








U 
s 
e 
r 
B 


U 

E 
B 


1 

lUI 
S 
A 


1 
lUI 

s 

B 






27 














NOTIFY 


ll\/IS_B sends a NOTIFY to IMS_A, containing 
IMS_A's de-registration 




28 
29 


200 OK 


IMS_A responds to the NOTIFY with a 200 OK 
User B is informed about de-registration 



















4.5.2.8 



Network initiated re-authentication by the S-CSCF 



Interoperability Test Description 


Identifier: 


TD ll\/IS REG 0006 


Summary: 


IMS networl< can initiate user re-authentication. 


Configuration: 


OF ROAM REG 


SUT 


IMS B 


References 


Test Purpose 


Specification Reference 


TP IMS 5094 01 


TS 124 229 [1], clause 5.4.1.6 112 


Use Case ref.: 


UC 01 R 1 




Pre-test 
conditions: 


• HSS of IMS_B is configured according to table 1 

• UE_B IP bearers established to IMS_A as per clause 4.2.1 

• UE_B registered in IMS_B using any user identity 

• IMS_A within the trust domain of IMS_B 

• Event received in S-CSCF of IMS B to re-authenticate UE B 


1 


i 


Test Sequence: 


step 




1 


IMS B network is triggered to re-authenticate user B 


2 


Verify that UE B shows successful registration 
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Interoperability Test Description 



Conformance 
Criteria: 



Check 



1 



TP_IMS_5094_01 in CFW steps 23 and 27 
ensure that { 
when { IMS_B receives a network_originated_reauthentication_event} 
then{ 
IMS_B sends a NOTIFY to UE_B 
containing a Request_URI 

indicating UEB and 
containing an Event_header 

indicating the reg_event_pacl<age and 
containing a Route_header 

indicating the original Route_header from SUBSCRIBE and 
containing a Message_Body 

containing for each registered_public_identity of UEB 
a registration_element 
(containing an aor_attribute 

indicating a registered_public_identity of UE_B and 
containing a state_attribute 

indicating active and 
containing a contact_subelement 
(containing an event_attribute 

indicating shortened and 
containing a state_attribute indicating active and 
containing an URI_subelement 

indicating the contact_address of UEB and 
containing an expiry_attribute) and 
IMS_B sends a NOTIFY to IMS_A - P-CSCF 
containing a Request_URI 

indicating the P-CSCF_SIP_URI of IMS_A and 
containing an Event_header 

indicating the reg_event_package and 
containing a Route_header 

indicating the original Route_header from SUBSCRIBE and 
containing a Message_Body 

containing for each registered_public_identity of UEB 
a registration_element 
(containing an aor_attribute 

indicating a registered_public_identity of UEB and 
containing a state_attribute 

indicating active and 
containing a contact_subelement 
(containing an event_attribute 

indicating shortened and 
containing a state_attribute indicating active and 
containing an URI_subelement 

indicating the contact_address of UEB and 
containing an expiry_attribute) } 
I 
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Step 


Direction 


IVIessage 


Comment 








U 
s 
e 
r 
B 


U 

E 
B 


1 

lUI 
S 
A 


1 

lUI 
S 
B 




















IMS B is triggered to re-authenticate user B 


23 








^ 




NOTIFY 


ll\/IS_B sends a NOTIFY to ll\/IS_A, containing 
UE B's re-authentication 


V 


24 


NOTIFY 


IIVIS_B sends a NOTIFY to UE_B, containing 
UE re-authentication 




25 


200 OK 


UE B responds to the NOTIFY with a 200 OK 




26 


200 OK 


IMS A forwards the 200 OK to IMS B 




27 


NOTIFY 


IIVIS_B sends a NOTIFY to IMS_A, containing 
IMS A's re-authentication 


V 


28 


200 OK 


IMS A responds to the NOTIFY with a 200 OK 


>. 


29 


REGISTER 


UE_B sends REGISTER containing 
authentication challenge response to IMS A 


^ 


30 


REGISTER 


IMS A forwards the REGISTER to IMS B 




31 


200 OK 


IMS B responds with 200 OK 




32 


200 OK 


IMS A forwards the 200 OK response to UE B 




33 


SUBSCRIBE 


IMS A sends a SUBSCRIBE to IMS B 


^ 


34 


200 OK or 
202 Accepted 


IMS_B responds with a 200 OK or 202 
Accepted 


^ 


35 


NOTIFY 


IMS_B sends a NOTIFY to IMS_A, containing 
UE B's registration status 




36 


200 OK 


IMS A responds to the NOTIFY with a 200 OK 




37 


SUBSCRIBE 


UE_B sends a SUBSCRIBE (reg event 
package) to IMS A 


^ 


38 


SUBSCRIBE 


IMS A forwards the SUBSCRIBE to IMS B 




39 


200 OK or 
202 Accepted 


IMS_B responds to the SUBSCRIBE with a 200 
OK or 202 Accepted 


^ 


40 


200 OK or 
202 Accepted 


IMS_A forwards the 200 OK or 202 Accepted 
response to UE B 




41 


NOTIFY 


IMS_B sends a NOTIFY to IMS_A, containing 
UE B's registration status 


> 


42 


NOTIFY 


IMS A forwards the NOTIFY to UE B 




43 


200 OK 


UE B responds to the NOTIFY with a 200 OK 




44 


200 OK 


IMS A forwards the 200 OK to IMS B 


45 




d 










User B is informed about successful registration 



4.5.2.9 



First time registration in a visited IMS network with topology hiding 



Interoperability Test Description 


Identifier: 


TD IMS REG 0007 


Summary: 


First time registration via a visited IMS network with topology hiding. 


Configuration: 


CF ROAM REG 


SUT 


IMS A 


References 


Test Purpose 


Specification Reference 


TP IMS 5134 01 


TS 124 229 [1], clause 5.10.4.1 115 


TP IMS 5405 01 


TS 124 229 [1], clause 5.10.2.2 V 


Use Case ref.: 


UC 01 R 


, 


Pre-test 
conditions: 


• HSS of IMS_B is configured according to table 1 

• UE_B IP bearers established to IMS_A as per clause 4.2.1 

• UE_B is not registered 

• IMS A is configured for topology hiding 


1 ^ 




Test Sequence: 


Step 




1 


User B registers in IMS B using any user identity 


2 


Verify that UEB shows successful registration 


I 




^^^^B ^ 




Conformance 
Criteria: 


Check 




1 


TP_IMS_5134_01 in CFW step 3, 7 (REGISTER): 
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Interoperability Test Description 






ensure that { 
when { UE B sends a REGISTER to IMS A } 
then { IMS_A sends the REGISTER to IMS_B 

containing an additional topmost Path header 
indicating the IBCF SIP URI of IMS A } 
} 


2 


TP_IMS_5405_01 in CFW step 10, 15 (SUBSCRIBE): 
ensure that { 
when { UE B sends a SUBSCRIBE to IMS B} 
then { IMS_A sends the SUBSCRIBE to IMS_B 
containing a Via_header 
containing (encrypted_consecutive_header_entries and 
a tokenized-by_parameter) and 
containing a Record-Route_header 
containing (encrypted_consecutive_header_entries and 
a tokenized-by_parameter) and 
containing a Route_header 
containing (encrypted_consecutive_header_entries and 
a toi<enized-by_parameter) and 
not containing (a P-Charging-Vector_header and 

a P-Charging-Function-Addresses header) } 
) 



Step 


Direction 


Message 


Comment 








U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


1 

M 
S 
B 






1 




^ 










User B registers in IMS B 


2 






V 






REGISTER 


UE B sends a REGISTER to IMS A 




3 


REGISTER 


IMS A forwards the REGISTER to IMS B 


^ 


4 


401 Unauthorized 


IMS B responds with 401 Unauthorized to 
IMS A 


V 


5 


401 Unauthorized 


IMS A forwards the 401 Unauthorized to UE B 


^. 


6 


REGISTER 


UE_B sends the same REGISTER containing 
authentication challenge response to IMS A 




7 


REGISTER 


IMS A forwards the REGISTER to IMS B 


^ 


8 


200 OK 


IMS B responds with 200 OK 


V 


9 


200 OK 


IMS A forwards the 200 OK response to UE B 




10 


SUBSCRIBE 


IMS A sends a SUBSCRIBE to IMS B 




11 


200 OK or 202 
Accepted 


IMS_B responds with a 200 OK or 202 
Accepted 




12 


NOTIFY 


IMS_B sends a NOTIFY to IMS_A, containing 
UE B's registration status 


N. 


13 


200 OK 


IMS A responds to the NOTIFY with a 200 OK 




14 


SUBSCRIBE 


UE_B sends a SUBSCRIBE (reg event 
package) to IMS A 


^ 


15 


SUBSCRIBE 


IMS A forwards the SUBSCRIBE request to 
IMS B 




16 


200 OK or 
202 Accepted 


IMS_B responds to the SUBSCRIBE with a 200 
OK or 202 Accepted 


^ 


17 


200 OK or 
202 Accepted 


IMS_A forwards the 200 OK or 202 Accepted 
response to UE B 




18 


NOTIFY 


IMS_B sends a NOTIFY to IMS_A, containing 
UE B's registration status 




19 


NOTIFY 


IMS A forwards the NOTIFY to UE B 


N. 


20 


200 OK 


UE B responds to the NOTIFY with a 200 OK 




21 


200 OK 


IMS A forwards the 200 OK to IMS B 




22 














User B is informed about successful registration 
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4.5.3 Initial Dialog or Subsequent Procedures 



4.5.3.1 



Initial INVITE Dialog Procedures 



4.5.3.1.1 



Initial INVITE Request Procedures - Originating 



4.5.3.1.1.1 



Default SIP URI with DNS/ENUM lookup procedure 



Interoperability Test Description 


Identifier: 


ID IMS CALL 0001 


Summary: 


IMS network can handle establishment of dialogs for users with default SIP URIs and 
resolve Tel URI E.164 numbers. 


Configuration: 


CF INT CALL 


SUT 


IMS A and IMS B 


References 


Test Purpose 


Specification Reference 


TP IMS 5097 01 


TS 124 229 [1], clause 5.4.3.2 11 


TP IMS 5097 02 


TS 124 229 [1], clause 5.4.3.2 HI 


TP IMS 5097 04 


TS 124 229 [1], clause 5.4.3.2 HI 


TP IMS 5107 02 


TS 124 229 [1], clause 5.4.3.2 1149 


TP IMS 5107 01 


TS 124 229 [1], clause 5.4.3.2 149 


TP IMS 5115 01 


TS 124 229 [1], clause 5.4.3.3 139 


TP IMS 5115 03 


TS 124 229 [1], clause 5.4.3.3 1139 


TP IMS 5115 02 


TS 124 229 [1], clause 5.4.3.3 139 


TP IMS 5115 04 


TS 124 229 [1], clause 5.4.3.3 1139 


TP IMS 5131 01 


TS 124 229 [1], clause 5.3.2.1 137 


TP IMS 5131 02 


TS 124 229 [1], clause 5.3.2.1 137 


Use Case ref.: 


UC 02 1 1 


Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UE_A and UE_B have IP bearers established to their respective IMS networks 
as per clause 4.2.1 

• UE_A is registered in IMS_A as userSIP_priv according to table 1 

• UE_B is registered in IMS_B as userSIP_priv according to table 1 

• IMS_A within the trust domain of IMS_B 

• Common DNS is configured with an ENUM entry for the Tel URI E.164 Number 
of users IP of IMS B 


Test Sequence: 


Step 




1 


User A calls user B's Tel URI (i.e. userSIP in IMS B) 


2 


Verify that user B is informed of incoming call of User A 


3 


Verify that user A is informed that UE B is ringing 


4 


User B answers the call 


5 


Verify that user A is informed that call has been answered 


6 


Verify that user B is informed that the call is established 


7 


User A ends the call 


8 


Verify with UE B that call has been released 


9 


Verify with UE A that call has been released 
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Interoperability Test Description 



Conformance 
Criteria: 



Check 



1 



TP_IMS_5097_01 in CFW step 4 (INVITE): 
ensure that { 

when { UE_A sends an initial INVITE to UE_B } 
then { IMS_B receives the initial INVITE 
not containing a Route_header 

indicating the S-CSCF_SIP_URI of IMS_A 
containing a P-Charging-Vector_header 
(containing an icid_parameter and 
containing a orig-ioi_parameter indicating IMS_A and 
not containing an access-network-charging-info_parameter and 
not containing a term-ioi_parameter) and 
containing a Record- Route_header 
indicating the originating S-CSCF_SIP_URI and 
not containing a P- access-network-info header} 
} 



TP_IMS_5097_02 in CFW step 4 (INVITE): 
ensure that { 
when { UE_A sends an initial INVITE to UE_B 

} 
then { IMS_B receives the initial INVITE 

containing a P-Asserted-ldentity_header 

indicating the SIP_URI of UE_A 
and 

containing a P-Asserted-ldentity_header 
indicating the Tel_URI of UE_A } 
1 



TP_IMS_5097_04 in CFW step 4 (INVITE): 
ensure that { 
when { UE_A sends an initial INVITE to UE_B 
containing a Request_URI 
indicating a Tel_URI} 
then { IMS_A sends a DNS_Query to DNS 

containing the Tel_URI_E.164_Number } 
when { IMS_A receives DNS_Response from DNS 

containing a NAPTR_Resource_Record 
indicating the SIP_URI of UE_B } 
then { IMS_A sends the initial INVITE to IMS_B 
containing a Request_URI 

indicating the SIP_URI of UE_B 
containing a P-Charging-Vector_header 
not containing an access-network-charging-info_parameter 
} 
} 



TP_IMS_5107_02 in CFW step 19 (ACK): 
ensure that { 
when { UE_A sends ACK to UE_B } 
then { IMS_B receives the ACK 

not containing Route_header 
indicating the S-CSCF_SIP_URI of IMS_A } 
} 



TP_IMS_5107_01 in CFW step 24A (BYE): 
ensure that { 
when { UE_A sends BYE to UE_B } 
then { IMS_B receives the BYE 

not containing Route_header 

indicating the S-CSCF_SIP_URI of IMS_A } 
I 
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Interoperability Test Description 



10 



11 



TP_IMS_5115_01 in CFW step 10 (180 Ringing): 
ensure that { 
when { UEB sends a 180_response to UEA } 
then { IMS_A receives the 180_response from IMS_B 
containing a P-Charging-Vector_header 
containing an orig-ioi_parameter 

indicating operatorjdentifier of IMS_A and 
containing a term-ioi_parameter 
indicating operatorjdentifier of ll\/IS_B 
_J 



TP_II\/IS_5115_03 in CFW step 10 (180 Ringing): 
ensure that { 
when { UEB sends a 1xx_response to UEA 

} 
then { ll\/IS_A receives the 1xx_response from ll\/IS_B 
containing a P-Asserted-ldentity_header 

indicating the SIP_URI of UE_B and 
containing a P-Asserted-ldentity_header 
indicating the Tel_URI of UE_B } 
1 



TP_II\/IS_51 15_02 in CFW step 15 (2xx): 
ensure that { 
when { UEB sends a 2xx_response to UEA } 
then { IMS_A receives the 2xx_response from i!\/IS_B 
containing a P-Charging-Vector_header 
containing an orig-ioi_parameter 

indicating operatorjdentifier of ll\/IS_A and 
containing a term-ioi_parameter 
indicating operatorjdentifier of ll\/IS_B 
J 



TP_II\/IS_511 5_04 in CFW step 15 (2xx): 
ensure that { 
when { UEB sends a 2xx_response to UE_A 

} 
then { IMS_A receives the 2xx_response from ll\/IS_B 
containing a P-Asserted-ldentity_header 

indicating the SIP_URI of UE_B and 
containing a P-Asserted-ldentity_header 
indicating the Tel_URI of UE_B} 
I 



TP_II\/IS_5131_01 in CFW step 10 (180 Ringing): 
ensure that { 

when { UEB sends a 180_response to UEA } 

then { IMS_B sends the 180_response to ll\/IS_A 

not containing a P-Charging-Function-Addresses_header} 
1 



TP_II\/IS_5131_02 in CFW step 15 (2xx) 

ensure that { 
when { UEB sends a 2xx_response to UEA } 
then { ll\/IS_A receives the 2xx_response from lf\/iS_B 

not containing a P-Charging-Function-Addresses_header} 

}_ 



Step 


Direction 


Message 


Comment 


-| 


U 
s 
e 
r 
A 


U 

E 
A 

^1 


1 

M 
S 
A 


D 
N 
S 


1 

M 
S 
B 


U 

E 
B 

1 


U 
s 
e 
r 
B 




1 Icpr A ralk 1 Iqpr R 


2 


















INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired medias and codecs that 
UE A supports 




3 


100 Trying 


IIVIS_A responds with a 100 Trying provisional 
response 
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Step 


Direction 


Message 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 
IVI 

s 

A 


D 
N 
S 


1 
IVI 

s 

B 


u 

E 
B 


U 
s 
e 
r 
B 






4a 


















DNS QUERY 


IIVIS_A sends DNS QUERY to common DNS 
containing E.164TELURI 




4b 


DNS 
RESPONSE 


Common DNS sends DNS RESPONSE 
containing NAPTR resource record to IIVIS A 




5 


INVITE 


IMS A forwards INVITE to IMS B 






6 


100 Trying 


IIVIS_B responds witli a 100 Trying provisional 
response 






7 


INVITE 


IMS B forwards INVITE to UE B 


8 




















User B is informed of incoming call of User A 




9 






/ 


^ 




^ 






180 Ringing 


UE_B responds to initial INVITE with 180 
Ringing to indicate that it has started alerting 




10 


180 Ringing 


IMS B forwards 180 Ringing response to 
IMS A 






11 


180 Ringing 


IMS A forwards the 180 Ringing response to 
UE A 




12 




d 
















User A is informed that UE B is ringing 


13 






User B answers call 


k 


14 






^ 












200 OK 


UE_B responds INVITE with 200 OK to indicate 
that the call has been answered 






15 


200 OK 


IMS_B forwards 200 OK response to IMS_A 




16 


200 OK 


IMS A forwards the 200 OK response to UE A 




17 




) 
















User A is informed that call has been answered 


18 


















ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 




19 


ACK 


IMS A forwards ACK to IMS B 






20 


ACK 


IMS B forwards ACK to UE B 


21 














) 






User B is informed that the call is established 


22A 






User A ends call 


) 


23A 


















BYE 


UE A releases the call with BYE 




24A 


BYE 


IMS A forwards BYE to IMS B 






25A 


BYE 


IMS B forwards BYE to UE B 


26A 














) 






User B is informed that call has ended 


27A 






^ 












200 OK 


UE B sends 200 OK for BYE 




28A 


200 OK 


IMS B forwards 200 OK response to IMS A 






29A 


200 OK 


IMS_A forwards the 200 OK response to UE_A 




30A 




^ 
















User B is informed that call has ended 



4.5.3.1.1.2 



Default SIP URI 



Interoperability Test Description 


Identifier: 


TD IMS CALL 0001 F 


Summary: 


IMS network can handle establishment of a call when the call is being offered to 
multiple terminals. 


Configuration: 


CF INT CALL 


SUT 


IMS A and IMS B 


References 


Test Purpose 


Specification Reference 


TP IMS 5097 01 


TS 124 229 [1], clause 5.4.3.2 11 


TP IMS 5107 02 


TS 124 229 [1], clause 5.4.3.2 149 


TP IMS 5107 01 


TS 124 229 [1], clause 5.4.3.2 149 


TP IMS 5115 01 


TS 124 229 [1], clause 5.4.3.3 139 


TP IMS 5115 02 


TS 124 229 [1], clause 5.4.3.3 139 


TP IMS 5131 01 


TS 124 229 [1], clause 5.3.2.1 137 


TP IMS 5131 02 


TS 124 229 [1], clause 5.3.2.1 137 



£75/ 



98 



ETSI TS 186 011-2 V2.3.1 (2010-04) 



Interoperability Test Description 


Use Case ref.: 


UC 12 1 






r 






1 



Pre-test 
conditions: 



HSS of IMS_A and of IMS B is configured according to table 1 

UE_A and UE_B have IP bearers established to their respective IMS networks 

as per clause 4.2.1 

UE_A is registered in IMS_A as userSIP_priv according to table 1 

UE_B is registered in IMS_B via UE_B1 and UE_B2 as userSIP according to 

table 1 

IMS A within the trust domain of IMS B 



Test Sequence: 



Step 



10 



11 



User A calls User B 



User B is informed of incoming call of User A on UEBI 



User B is informed of incoming call of User A on UE_B2 



User A is informed that a UE of User B is ringing 



User B answers call on UE B2 



User B is informed at UE_B1 that the call is no longer offered 



User A is informed that call has been answered 



User B is informed that the call is established 



User A ends the call 



Verify with UEB that call has been released 



Verify with UEA that call has been released 



Conformance 
Criteria: 



Checl< 



1 



TP_IMS_5097_01 in CFW step 4 (INVITE): 
ensure that { 

when { UE_A sends an initial INVITE to UE_B } 
then { IMS_B receives the initial INVITE 
not containing a Route_header 

indicating the S-CSCF_SIP_URI of IMS_A 
containing a P-Charging-Vector_header 
(containing an icid_parameter and 
containing a orig-ioi_parameter indicating IMS_A and 
not containing an access-network-charging-info_parameter and 
not containing a term-ioi_parameter) and 
containing a Record- Route_header 
indicating the originating S-CSCF_SIP_URI and 
not containing a P- access-network-info header} 
}_ 



TP_IMS_5107_02 in CFW step 28 (ACK): 
ensure that { 
when { UE_A sends ACK to UE_B } 
then { IMS_B receives the ACK 

not containing Route_header 
indicating the S-CSCF_SIP_URI of IMS_A } 
I 



TP_IMS_5107_01 in CFW step 33A (BYE): 
ensure that { 
when { UE_A sends BYE to UE_B } 
then { IMS_B receives the BYE 

not containing Route_header 
indicating the S-CSCF_SIP_URI of IMS_A } 
I 



TP_IMS_5115_01 in CFW step 10 and 17 (180 Ringing): 
ensure that { 
when { UEB sends a 180_response to UEA } 
then { IMS_A receives the 180_response from IMS_B 
containing a P-Charging-Vector_header 
containing an orig-ioi_parameter 

indicating operatorjdentifier of IMS_A and 
containing a term-ioi_parameter 
indicating operatorjdentifier of IMS_B 
1 



TP_IMS_51 1 5_02 in CFW step 24 (2xx): 
ensure that { 
when { UEB sends a 2xx_response to UEA } 
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Interoperability Test Description 






then { IMS_A receives the 2xx_response from IMS_B 
containing a P-Charging-Vector_header 
containing an orig-ioi_parameter 

indicating operatorjdentifier of ll\/IS_A and 
containing a term-ioi_parameter 
indicating operator identifier of II^S B 

} 




6 


TP_IMS_5131_01 in CFW step 10 and 17 (180 Ringing): 
ensure that { 

when { UEB sends a 180_response to UEA } 

then { IMS_B sends the 180_response to lf^S_A 

not containing a P-Charging-Function-Addresses header} 
} 


7 


TP_I1VIS_5131_02 in CFW step 25 (2xx) 

ensure that { 
when { UEB sends a 2xx_response to UEA } 
then { IMS_A receives the 2xx_response from IMS_B 

not containing a P-Charging-Function-Addresses header} 

} 



Step 


Direction 


Message 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 

B 


u 

E 
B 


U 
s 
e 
r 
B 






1 




> 














User A calls User B 


2 






V 










INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired medias and codecs that 
UE A supports 


^ 


3 


100 Trying 


ll\/IS_A responds with a 100 Trying provisional 
response 




4 


INVITE 


IMS A forwards INVITE to IMS B 




5 


100 Trying 


ll\/IS_B responds with a 100 Trying provisional 
response 




6 


INVITE 


IMS B forwards INVITE to UE B1 




7 


100 Trying 


UE_B1 optionally responds with a 100 Trying 
provisional response 




8 


















User B is informed on UE_B1 of incoming call of 
User A 


^ 




9 






^ 


^ 


^ 






180 Ringing 


UE_B1 responds to initial INVITE with 180 
Ringing to indicate that it has started alerting 




10 


180 Ringing 


IMS B forwards 180 Ringing response to 
IMS A 




11 


180 Ringing 


IMS A forwards the 1 80 Ringing response to 
UE A 




12 




« 














User A is informed that a UE of User B is ringing 


13 
















INVITE 


IMS B forwards INVITE to UE B2 




14 


100 Trying 


UE_B2 optionally responds with a 100 Trying 
provisional response 




15 


















User B is informed on UE_B2 of incoming call of 
User A 


^ 




16 








y 


^ 






180 Ringing 


UE_B2 responds to initial INVITE with 180 
Ringing to indicate that it has started alerting 




17 


180 Ringing 


IMS B forwards 2"^" 180 Ringing response to 
IMS A 




18 


180 Ringing 


IMS A forwards the 2"^ 180 Ringing response 
toUE A 




19 












« 






User B answers call at UE B2 


20 
















200 OK 


UE_B2 responds to INVITE with 200 OK to 
indicate that the call has been answered 




21 


CANCEL 


IMS B sends CANCEL request to UE B1 




22 


200 OK 


UE_B1 sends 200 OK response to the CANCEL 
request to IMS B 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






23 








^ 










UE_B1 informs user B that the call is no longer 
offered to this UE and stops ringing 




24 


200 OK 


IMS_B forwards 200 OK response to IMS_A 




25 


200 OK 


IMS A forwards the 200 OK response to UE A 




27 




^ 












ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 




28 


ACK 


IMS A forwards ACK to IIVIS B 




29 


ACK 


IMS B forwards ACK to UE B 




30 
T1 A 












^ 






User B is informed that the call is established 


32A 










> 






BYE 


UE A releases the call with BYE 




33A 


BYE 


IMS A forwards BYE to IMS B 




34A 


BYE 


IMS B forwards BYE to UE B 


36A 










^ 


? 




200 OK 


UE B sends 200 OK for BYE 




37A 


200 OK 


IMS_B forwards 200 OK response to IMS_A 




38A 
39A 


«— 




«— 
















200 OK 


IMS A forwards the 200 OK response to UE A 
User A is informed that call has ended 



4.5.3.1.1.3 



Default Tel URI 



Interoperability Test Description 


Identifier: 


TD IMS CALL 0002 


Summary: 


IMS network can handle establishment of dialogs for users with default TEL URIs. 


Configuration: 


CF INT CALL 


SUT 


IMS A and IMS B 


References 


Test Purpose 


Specification Reference 


TP IMS 5097 01 


TS 124 229 [1], clause 5.4.3.2 HI 


TP IMS 5097 02 


TS 124 229 [1], clause 5.4.3.2 11 


TP IMS 5107 02 


TS 124 229 [1], clause 5.4.3.2 1149 


TP IMS 5107 01 


TS 124 229 [1], clause 5.4.3.2 149 


TP IMS 5115 01 


TS 124 229 [1], clause 5.4.3.3 1139 


TP IMS 5115 03 


TS 124 229 [1], clause 5.4.3.3 1139 


TP IMS 5115 02 


TS 124 229 [1], clause 5.4.3.3 139 


TP IMS 5115 04 


TS 124 229 [1], clause 5.4.3.3 1139 


TP IMS 5131 01 


TS 124 229 [1], clause 5.4.3.3 137 


TP IMS 5131 02 


TS 124 229 [1], clause 5.3.2.1 1137 


Use Case ref.: 


UC 02 1 1 




Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UE_A and UE_B have IP bearers established to their respective IMS networks 
as per clause 4.2.1 

• UE_A is registered in IMS_A using userTEL_priv according to table 1 

• UE_B is registered in IMS_B using userTEL_priv according to table 1 

• IMS A within the trust domain of IMS B 


I J 


Test Sequence: 


Step 


1 


1 


User A calls user B (i.e. userTEL in IMS B) 


2 


Verify that user B is informed of incoming call of User A 


3 


Verify that user A is informed that UE B is ringing 


4 


User B answers the call 


5 


Verify that user A is informed that call has been answered 


6 


Verify that user B is informed that the call is established 


7 


User A ends the call 


8 


Verify with UE B that call has been released 




9 


Verify with UE A that call has been released 


F ^^^ 1 
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Interoperability Test Description 



Conformance 
Criteria: 



Clieck 



TP_IMS_5097_01 in CFW step 4 (INVITE): 
ensure that { 

when { UE_A sends an initial INVITE to UE_B } 
then { IMS_B receives the initial INVITE 
not containing a Route_header 

indicating the S-CSCF_SIP_URI of IMS_A 
containing a P-Charging-Vector_header 
(containing an icid_parameter and 
containing a orig-ioi_parameter indicating IMS_A and 
not containing an access-network-charging-info_parameter and 
not containing a term-ioi_parameter) and 
containing a Record- Route_header 
indicating the originating S-CSCF_SIP_URI and 
not containing a P- access-network-info header } 
I 



TP_IMS_5097_02 in CFW step 4 (INVITE) 
ensure that { 
when { UE_A sends an initial INVITE to UE_B 

} 
then { IMS_B receives the initial INVITE 

containing a P-Asserted-ldentity_header 

indicating the SIP_URI of UE_A 
and 

containing a P-Asserted-ldentity_header 
indicating the Tel_URI of UE_A} 
1 



TP_IMS_5107_02 in CFW step 19 (ACK): 
ensure that { 
when { UE_A sends ACK to UE_B } 
then { IMS_B receives the ACK 

not containing Route_header 
indicating the S-CSCF_SIP_URI of IMS_A } 
1 



TP_IMS_5107_01 in CFW step 24A (BYE): 
ensure that { 
when { UE_A sends BYE to UE_B } 
then { IMS_B receives the BYE 

not containing Route_header 
indicating the S-CSCF_SIP_URI of IMS_A } 
1 



TP_IMS_5115_01 in CFW step 10 (180 Ringing): 
ensure that { 
when { UEB sends a 180_response to UEA } 
then { IMS_A receives the 180_response from IMS_B 
containing a P-Charging-Vector_header 
containing an orig-ioi_parameter 

indicating operatorjdentifier of IMS_A and 
containing a term-ioi_parameter 
indicating operatorjdentifier of IMS_B 



TP_IMS_5115_03 in CFW step 10 (180 Ringing): 
ensure that { 
when { UEB sends a Ixxresponse to UE_A 

} 
then { IMS_A receives the Ixxresponse 

containing a P-Asserted-ldentity_header 

indicating the SIP_URI of UE_B and 
containing a P-Asserted-ldentity_header 
indicating the Tel_ URI of UE_B} 
} 



TP_IMS_51 15_02 in CFW step 15 (2xx): 

ensure that { 
when { UEB sends a 2xx_response to UEA } 
then { IMS_A receives the 2xx_response from IMS_B 
containing a P-Charging-Vector_header 

containing an orig-ioi_parameter 
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Interoperability Test Description 






indicating operatorjdentifier of IMS_A and 
containing a term-ioi_parameter 
indicating operator identifier of IMS B 
} 




8 


TP_IMS_5115_04 in Cl^ step 15 (2xx): 
ensure ttiat { 
wfien { UE B sends a 2xx response to UE A 

} 
ttien { IMS_A receives tlie 2xx_response 

containing a P-Asserted-ldentity_lieader 

indicating tlie SIP_URI of UE_B and 
containing a P-Asserted-ldentity lieader 
indicating tlie Tel URI of UE B} 
} 


9 


TP_IMS_5131_01 in CFW step 10 (180 Ringing): 
ensure that { 

wfien { UEB sends a 180_response to UEA } 

then { IMS_B sends the 180_response to IMS_A 

not containing a P-Charging-Function-Addresses header} 
} 


10 


TP_IMS_5131_02 in CFW step 15 (2xx) 

ensure that { 
when { UEB sends a 2xx_response to UEA } 
then { IMS_A receives the 2xx_response from IMS_B 

not containing a P-Charging-Function-Addresses header} 

} 



Step 


Direction 


Message 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






1 




> 














User A calls User B 


2 










V 






INVITE 


UE_A sends INVITE with the first SDR offer 
indicating all desired medias and codecs that 
UE A supports 


^ 


3 


100 Trying 


ll\/IS_A responds with a 100 Trying provisional 
response 




4 


INVITE 


IMS A forwards INVITE to IMS B 




5 


100 Trying 


ll\/IS_B responds with a 100 Trying provisional 
response 




6 


INVITE 


IMS B forwards INVITE to UE B 




7 


100 Trying 


UE_B optionally responds with a 100 Trying 
provisional response 




8 












» 






User B is informed of incoming call of User A 


9 










^ 






180 Ringing 


UE_B responds to initial INVITE with 180 
Ringing to indicate that it has started alerting 




10 


180 Ringing 


IMS B forwards 180 Ringing response to 
IMS A 




11 


180 Ringing 


IMS A forwards the 1 80 Ringing response to 
UE A 




12 




d 














User A is informed that UE B is ringing 


13 






User B answers call 


^ 


14 






^ 




^ 






200 OK 


UE_B responds INVITE with 200 OK to indicate 
that the call has been answered 




15 


200 OK 


IMS_B forwards 200 OK response to IMS_A 




16 


200 OK 


IMS_A forwards the 200 OK response to UE_A 




17 




<i 














User A is informed that call has been answered 


18 
















ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 




19 


ACK 


IMS A forwards ACK to IMS B 




20 










*. 






ACK 


IMS B forwards ACK to UE B 




21 












» 






User B is informed that the call is established 


22A 




V 














User A ends call 




/ 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






23A 












v. 




BYE 


UE A releases the call with BYE 




24A 


BYE 


IMS A forwards BYE to IIVIS B 




25A 

Oft A 


BYE 


IMS B forwards BYE to UE B 




27A 










^ 






200 OK 


UE B sends 200 OK for BYE 




28A 


200 OK 


IMS B forwards 200 OK response to IMS 




29A 
30A 


200 OK 


IMS A forwards the 200 OK response to UE A 
User B is informed that call has ended 










— ^ 



4.5.3.1.1.4 



Rejection of call from barred user 



Interoperability Test Description 



Identifier: 



TD IMS CALL 0003 



Summary: 



IMS network does not establish call to barred user. 



Configuration: 



CF INT CALL 



SUT 



IMS B 



References 



Test Purpose 



TP IMS 5108 05 



Specification Reference 



TS 124 229 [1], clause 5.4.3.3 1|1 



Use Case ref. 



UC 02 I 



Pre-test 
conditions: 



HSS of IMS_A and of IMS B is configured according to table 1 

UEA and UEB have IP bearers established to their respective IMS networks 

as per clause 4.2.1 

UE_A is registered in IMS_A using any user identity 

UE_B is registered in IMS_B using any user identity 

IMS_A within the trust domain of IMS_B 

User B has two public identities in IMS_B out of which one of has been barred 



Test Sequence: 



Step 



User A calls user B using barred user identity 



Verify that user A is informed that call cannot be established 



Conformance 
Criteria: 



Check 



1 



TP_IMS_5108_05 in CFW step 6 (404 response): 
ensure that { 
when { UEA sends an initial INVITE to UEB and 
IMS_A sends the INVITE to IMS_B 
containing a Request_URI 

indicating a barred_user in IMS_B } 
then { IMS_B sends 404_response to IMS_A } 
1 



Step 


Direction 


Message 


Comment 


1 


U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


c 

E 


A 

1 

I 


L 

E 
E 


J 

i 


I 

E 


J 

i 

r 
3 




1 Jcpr A rall<^ 1 i^pr R 


2 
















INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired medias and codecs that 
UE A supports 


^ 


3 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




4 


INVITE 


IMS A forwards INVITE to IMS B 




5 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






6 
















404 Not 
Found 


IMS_B responds to the INVITE with 404 Not 
Found 




7 

Q 


404 Not 
Found 


IMS A forwards the 404 Not Found response to 
UE A 




9 




i 












ACK 


UE A acknowledges the response 




10 


ACK 


IMS A forwards the ACK to IMS B 





















4.5.3.1.1.5 



Rejection of call to non-existing user 



Interoperability Test Description | 


Identifier: 


ID IMS CALL 0004 


Summary: 


IMS network rejects call to non existing user. 


Configuration: 


CF INT CALL 


SUT 


IMS B 


References 


Test Purpose 


Specification Reference 


TP IMS 5132 01 


TS 124 229 [1], clause 5.3.2.1 1128 


Use Case ref.: 


UC 01 1 1 




Pre-test 
conditions: 


• HSS of IMS_A and is configured according to table 1 

• UE_A have IP bearers established to their respective IMS networks as per 
clause 4.2.1 

• UEA is registered in IMS_A using any user identity 

• IMS A within the trust domain of IMS B 




Test Sequence: 


Step 




1 


User A calls user B indicating a non existing identity within IMS B domain 


2 


Verify that user A is informed that call cannot be established 


1 1 


Conformance 
Criteria: 


Check 




1 


TP_IMS_5132_01 in CFW step 6 (404 Not Found): 
ensure that { 
when { UEA sends an initial INVITE 
containing a Request_URI 
indicating a non existing user in IMS B and 
IMS_A sends the INVITE to IMS_B } 
then { IMS B sends an appropriate (e.g. 404 or 604) to IMS A } 
} 



Step 


Direction 


Message 


Comment 


1 


U 
s 
e 
r 
A 


u 

E 
A 

— ^ 


1 

M 
S 
A 


c 
E 


A 
> 


L 

E 
E 


J 


I 

; 
( 

E 


J 

> 

r 
J 




User A calls User B 


2 
















INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired medias and codecs 
that UE A supports 




3 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




4 


INVITE 


IMS A forwards INVITE to IMS B 




5 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 




6 


404 Not 
Found 


IMS B responds with 404 Not Found to 
IMS A 




7 


404 Not 
Found 


IMS A forwards the 404 Not Found response to 
UE A 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






8 


















User A is informed that called user does not 
exist 




9 








V 








ACK 


UE_A acknowledges the receipt of a 404 final 
response 




10 


ACK 


IMS A forwards the ACK to IIVIS B 





















4.5.3.1.1.6 



Rejection of call to unavailable user 



Interoperability Test Description 



Identifier: 



TD IMS CALL 0005 



Summary: 



IMS network does not establish a call for unavailable user. 



Configuration: 



CF INT CALL 



SUT 



IMS B 



References 



Test Purpose 



IP IMS 5133 01 



Specification Reference 



TS 124 229 [1], clause 5.3.2.1 1129 



Use Case ref. 

Pre-test 
conditions: 



Test Sequence: 



Conformance 
Criteria: 



UC 01 I 



"3 



HSS of IMS_A and IMS_B is configured according to table 1 

UE_A has IP bearers established to their respective IMS networks as per 

clause 4.2.1 

UE_A is registered in IMS_A using any user identity 

UE_B is not registered in IMS_B 



Step 



User A calls a valid user B identity 



Verify that user A is informed that user B is not reachable or equivalent 



Check 



1 



TP_IMS_5133_01 in CFW step 6 (4xx); 

ensure that { 
when { UE_A sends INVITE to UE_B } 
then { IMS_B sends a 4xx_response to IMS_A ) 

I 



Step 


Direction 


Message 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






1 




» 














User A calls User B 


2 
















INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired medias and codecs that 
UE A supports 




3 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




4 


INVITE 


IMS A forwards INVITE to IMS B 




5 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 


^ 


6 


4xx 


IMS_B responds with 4xx to IMS_A 




7 


4xx 


IMS A forwards the 4xx response to UE A 




8 




^ 














User A is informed that called user is not 
reachable or equivalent 




9 






N. 










ACK 


UE_A acknowledges the receipt of a 4xx final 
response 




10 


ACK 


IMS A forwards the ACK to IMS B 
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4.5.3.1.1.7 



Initial request to non-registered user with terminating unregistered filter criterion 



Test Description 


Identifier: 


TD IMS CALL 0006 


Summary: 


IMS network can handle initial request to non-registered user with terminating 
unregistered filter criterion. 


Configuration: 


CF INT CALL 


SUT 


IMS B 


References 


Test Purpose 


Specification Reference 


TP IMS 5109 01 


TS 124 229 [1], clause 5.3.2.1 1133 


Use Case Ref.: 


UC 01 1 1 


^H^K 


Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UE_A and UE_B have IP bearers established to their respective IMS networks 
as per clause 4.2.1 

• UE_A has no filter criteria defined in HSS 

• IMS B has terminating unregistered criterion set for UE B on INVITE indicating 
SESSION_TERMINATED option and forward the INVITE to AS_B 

• AS_B is unreachable from IMS_B 

• UE_A registered using any user identity 

• UE B not registered as userNOAS priv according to table 1 


Test Sequence: 

1 H 


Step 




1 


User A calls user B (i.e. userNOAS in IMS B) 


2 


Verify that user A is informed that call cannot be established 


Pass Criteria: 


Check 




1 


TP_IMS_5109_01 in CFW step 6 (Error Response): 
ensure that { 

when { UE A sends INVITE to UE B } 

then { IMS_B receives the INVITE and 

sends (a 408 response or a 5xx response) to IMS A 

} 
I 



Step 


Direction 


Message 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






1 




> 














User A calls User B 


2 








V 








INVITE 


UE_A sends INVITE with the first SDP offer indicating 
all desired medias and codecs that UE A supports 




3 


100 Trying 


IMS A responds with a 100 Trying provisional response 




4 


INVITE 


IMS A forwards INVITE to IMS B 




5 


100 Trying 


IMS B responds with a 100 Trying provisional response 


^ 


6 


408 Request 
Timeout or 
5xx Response 


ll\/IS_B responds witfi 4xx to IMS_A 




7 
8 


408 Request 
Timeout or 
5xx Response 


IMS_A forwards the 4xx response to UEA 

User A is informed that called user is not reachable 


^ 
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4.5.3.1.2 



Dialogue Procedures with Roaming 



4.5.3.1.2.1 



Normal call 



Interoperability Test Description | 


Identifier: 


ID IMS CALL 0007 


Summary: 


IMS network handles normal call while UE_B is roaming without topology hiding 
correctly. 


Configuration: 


CF ROAM CALL 


SUT 


IMS A 


References 


Test Purpose 


Specification Reference 


IP IMS 5046 01 


TS 124 229 [1], clause 5.2.6.3 15 


IP IMS 5070 01 


TS 124 229 [1], clause 5.2.7.3 116 


IP IMS 5301 01 


TS 124 229 [1], clause 5.4.3.3 156 


IP IMS 5055 01 


TS 124 229 [1], clause 5.2.6.4 115 


IP IMS 5055 02 


TS 124 229 [1], clause 5.2.6.4 1115 


IP IMS 5108 01 


TS 124 229 [1], clause 5.4.3.3 HI 


Use Case ref.: 


UC 02 R J 


Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UEA and UEB have IP bearers established to IMS_A as per clause 4.2.1 

• UE_A is registered in IMS_A using any user identity 

• UE_B is registered in IMS_B via IMS_A using any user identity 

• IMS_A within the trust domain of IMS_B 

• A Service-Route header list exists for UE B in P-CSCF 




Test Sequence: 


Step 




1 


User B calls User A 


2 


Verify that user A is informed of incoming call of User B 


3 


Verify that user B is informed that UE A is ringing 


4 


User A answers call 


5 


Verify that user B is informed that call has been answered 


6 


Verify that user A is informed that the call is established 


7 


User A ends call 


8 


Verify that user B is informed that call has ended 


9 


Verify that user A is informed that call has ended 
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Interoperability Test Description 



Conformance 
Criteria: 



Check 



TP_IMS_5046_01 in CFW step 4 (INVITE) 
ensure that { 
when { IMS_A receives an initial INVITE from UEB } 
then { IMS_A sends the INVITE to IMS_B 
containing a topmost Route_header 

not indicating the P-CSCF_SIP_URI of IMS_A and 
containing a Route_header 
indicating the "list of Service Route header URIs 
from the registration" and 
containing an additional Via_header 
containing ( the P-CSCF_via_port_number and 
(the P-CSCF-FQDN_address or 
the P-CSCF-IP_address)) of IMS_A and 
containing an additional topmost Record-Route_header 
indicating (the P-CSCF_port_number 

'where it awaits subsequent requests' from UEA and 
(the P-CSCF-FQDN_address or 
the P-CSCF-IP_address)) of IMS_A and 
not containing P-Preferred-ldentity_header and 
containing a P-Asserted-ldentity_header 

containing an address of UEB and 
containing a P-Charging-Vector_header 
containing an icid_parameter } 
1 



TP_IMS_5070_01 in CFW step 7 (100 Trying) 

ensure that { 
when { IMS_A receives an initial INVITE from IMS_B } 
then { IMS_A sends a 100_response to IMS_B 
} 

I 



TP_IMS_5055_01 in CFW step 12 (180 Ringing) 
ensure that { 
when { IMS_A receives a 180_response from UEA } 
then { IMS_A sends a 180_response to IMS_B 
containing a Record-Route_header 
containing the P-CSCF_SIP_URI and 

P-CSCF_port_number of IMS_A 
"where it expects subsequent requests" and 
not containing a comp_parameter and 
not containing a P-Preferred-ldentity_header and 
containing a P-Asserted-ldentity_header 
indicating the public identity "sent in P-Called_Party-ID header 
sent in the initial request" } 
1 



TP_II\/IS_5055_02 in CFW step 18 (200 OK) 
ensure that { 
when { IMS_A receives a 200_response from UEA } 
then { IMS_A sends the 200_response to IMS_B 
containing a Record-Route_header 
containing the P-CSCF_SIP_URI and 

P-CSCF_port_number of IMS_A 
"where it expects subsequent requests" and 
not containing a comp_parameter and 
not containing a P-Preferred-ldentity_header and 
containing a P-Asserted-ldentity_header 
indicating the address "sent in P-Called_Party-ID header 
sent in the initial request" 



} 



} 
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Interoperability Test Description 



TP_IMS_5108_01 in CFW step 6 (INVITE): 
ensure that { 
when { UE_B sends an initial INVITE to UE_A 
IMS_A sends the INVITE to IMS_B 
containing a P-Charging-Vector_header 
containing an icid_parameter } 
then { IMS_B sends the INVITE to IMS_A 
containing no Route_header 

indicating the S-CSCF_SIP_URI of IMS_B and 
containing a P-Charging-Vector_header 
containing the same icid_parameter and 
not containing ioi_parameters 
containing a Record-Route_header 
containing the S-CSCF_SIP_URI of IMS_B } 
} 



Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


1 

M 
S 
B 






1 








» 










User B calls User A 


2 










N. 






INVITE 


UE_B sends INVITE with the first SDP offer 
indicating all desired media and codecs that 
UE B supports 


^ 


3 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




4 


INVITE 


IMS_A forwards INVITE to IMS_B 




5 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 


^ 


6 


INVITE 


IMS_B forwards the INVITE to IMS_A 




7 


100 Trying 


IMS_A responds with a 100 Trying 
provisional response 




8 


INVITE 


IMS_A forwards the INVITE to UE_A 






V 


9 


100 Trying 


UE_A optionally responds with a 100 Trying 
provisional response 








10 




i 














User A is informed of incoming call of User B 


11 
















180 Ringing 


UE_A responds to initial INVITE with 180 
Ringing to indicate that it has started alerting 






^ 


12 


180 Ringing 


IMS A forwards 180 Ringing response to 
IMS B 




13 


180 Ringing 


IMS B forwards the 180 Ringing response to 
IMS A 




14 


180 Ringing 


IMS A forwards the 180 Ringing response to 
UE B 




15 




> 




i 










User B is informed that UE_A is ringing 


16 






User A answers call 


17 












>. 




200 OK 


UE_A responds INVITE with 200 OK to indicate 
that the call has been answered 








18 


200 OK 


IMS_A forwards 200 OK response to IMS_B 




19 


200 OK 


IMS_B forwards the 200 OK response to IMS_A 




20 


200 OK 


IMS_A forwards the 200 OK response to UE_B 




21 








d 










User B is presented that call in process 


22 












V 




ACK 


UE B acknowledges the receipt of 200 OK for 
INVITE 




23 


ACK 


IMS_A forwards ACK to IMS_B 




24 


ACK 


IMS_B forwards ACK to IMS_A 




25 


ACK 


IMS_A forwards ACK to UE_A 








26 




d 














User A is informed that the call is in progress 


27A 


» 




User A ends call 


28A 










V 






BYE 


UE_A releases the call with BYE 








29A 


BYE 


IMS_A forwards BYE to IMS_B 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 
IVI 

s 

A 


1 

M 
S 
B 






30A 










^ 






BYE 


IMS_B forwards BYE to IMS_A 




31A 
32A 


BYE 


IMS_A forwards BYE to UE_B 

User B is informed that call has ended 










«— 











4.5.3.1.2.2 



Normal call with hold/resume 



Interoperability Test Description 


Identifier: 


ID IMS CALL 0008 


Summary: 


IMS network handles subsequent INVITEs correctly in case of a user initiated call hold 
and resume when home caller puts roaming user on hold and resumes call. 


Configuration: 


OF ROAM CALL 


SUT 


IMS A 


References 


Test Purpose 


Specification Reference 


IP IMS 5081 01 


TS 124 229 [1], clause 5.2.9.2 HI 


IP IMS 5082 01 


TS 124 229 [1], clause 5.2.9.2 112 


TP IMS 5120 01 


TS 124 229 fll, clause 5.4.3.3 1148 


Use Case ref.: 

■ ^^^^^^ 


UC 03 R J 


Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UEA and UEB have IP bearers established to their respective IMS networks 
as per clause 4.2.1 

• UE_A configured to perform user initiated hold/resume using INVITE 

• UE_A is registered in IMS_A using any user identity 

• UE B is registered in IMS B via IMS A using any user identity 


^^^^^^^^^^1 




Test Sequence: 


Step 




1 


User A calls User B 


2 


Verify that user B is informed of incoming call of User A 


3 


Verify that user A is informed that UE A is ringing 


4 


User B answers call 


5 


Verify that user A is informed that call has been answered 


6 


Verify that user B is informed that call is established 


7 


User A puts call on hold 


8 


Verify that user B is informed that call is on hold 


9 


Verify that user A is informed that call is on hold 


10 


User A resumes call 


11 


Verify that user B is informed that call is resumed 


12 


Verify that user A is informed that call is resumed 


13 


User A ends call 


14 


Verify that user B is informed that call has ended 


15 


Verify that user A is informed that call has ended 


1 


1 


Conformance 
Criteria: 


Check 




1 


TP_IMS_5081_01 in CFW step 41 A and 60A (100 Trying): 
ensure that { 

when {UE A sends a subsequent INVITE to UE B and 
IMS_A receives the INVITE from IMS_B } 

then {IMS A sends a 100 response to IMS 8} 
} 


2 


TP_IMS_5082_01 in CFW step 46A and 65A (200 OK): 
ensure that { 
when { IMS_A receives a 200_response from UEB } 
then { IMS_A sends the 200_response to IMS_B 
containing a P-Charging-Vector_header 
containing an updated 

access-network-charging-info_parameter 
} 
} 
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Interoperability Test Description 



TP_IMS_5120_01 in CFW step 40A and 59A (INVITE): 
ensure that { 

when { UEA sends a subsequent INVITE to UEB } 
then { IMS_A receives the INVITE from IMS_B 
containing a topmost Route_header 

not indicating the S-CSCF_SIP_URI 
containing a Record-Route_header 
containing the S-CSCF_SIP_URI } 
I 



Step 


Direction 


Message 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


1 

M 
S 
B 






34 




> 














User B is presented that call is in progress 


i 


35A 






User A puts call on hold 


36A 










V 






INVITE 


UE_A sends relNVITE message indicating 
media attribute "sendonly" (Call Hold) 








37A 


100 Trying 


ll\/IS_A responds with a 100 Trying provisional 
response 






^ 


38A 


INVITE 


IMS A forwards INVITE to IMS B 


^ 


39A 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 




40A 


INVITE 


IMS B forwards INVITE to IMS A 


>. 


41 A 


100 Trying 


IMS_A responds with a 100 Trying 
provisional response 




42A 


INVITE 


IMS A forwards INVITE to UE B 




43A 


100 Trying 


UE_B optionally responds with a 100 Trying 
provisional response 




44A 








d 










User B is informed that call is on hold 


45A 






^ 










200 OK 


UE_B responds to INVITE with 200 OK 
indicating attribute "recvonly" inactive 




46A 


200 OK 


IMS_A forwards 200 OK response to IMS_B 




47A 


200 OK 


IMS B forwards 200 OK response to IMS A 




48A 


200 OK 


IMS A forwards the 200 OK response to UE A 








49A 


ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 






^ 


50A 


ACK 


IMS A forwards ACK to IMS B 




51A 


ACK 


IMS B forwards ACK to IMS A 




52A 


ACK 


IMS A forwards ACK to UE B 




53A 




i 














User A is informed that call is on hold 


54A 


> 




User A resumes call 


55A 












>. 




INVITE 


UE_A sends relNVITE message indicating 
media attribute "sendrecv" (Call Resume) 








56A 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 








57A 


INVITE 


IMS A forwards INVITE to IMS B 




58A 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 


^ 


59A 


INVITE 


IMS B forwards INVITE to IMS A 


>. 


60A 


100 Trying 


IMS_A responds with a 100 Trying 
provisional response 




61A 


INVITE 


IMS A forwards INVITE to UE B 


N. 


62A 


100 Trying 


UE_B optionally responds with a 100 Trying 
provisional response 




63A 








d 










User B is informed that call is resumed 


64A 












>. 




200 OK 


UE_B responds to INVITE with 200 OK 
indicating media attribute "sendrecv" 




65A 


200 OK 


IMS_A forwards 200 OK response to IMS B 




66A 


200 OK 


IMS B forwards 200 OK response to IMS A 




67A 
















200 OK 


IMS A forwards the 200 OK response to UE A 








68A 




d 














User A is informed that call is resumed 
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4.5.3.1.2.3 



Subsequent request (other than target refresh) 



Interoperability Test Description 


Identifier: 


TD IMS CALL 0009 


Summary: 


IMS network handles routing information in subsequent requests (other than target 
refresh) received from the UE before forwarding them to another IMS networl<. 


Configuration: 


OF ROAM CALL 


SUT 


IMS A 


References 


Test Purpose 


Specification Reference 


IP IMS 5052 01 


TS 124 229 [1], clause 5.2.6.3 1156 


Use Case ref.: 


UC 02 R 


1 


Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UE_B has IP bearers established to their respective IMS networks as per 
clause 4.2.1 

• UE_A registered in IMS_A using any user identity 

• UE B is registered in IMS B via IMS A using any user identity 


Test Sequence: 


Step 




1 


User B calls User A 


2 


Verify that user A is informed of incoming call of User B 


3 


Verify that user B is informed that UE A is ringing 


4 


User A answers call 


5 


Verify that user B is informed that call has been answered 


6 


Verify that user A is informed that the call is established 


7 


User B ends call 


8 


Verify that user A is informed that call has ended 


9 


Verify that user B is informed that call has ended 


L 






Conformance 
Criteria: 


Check 




1 


TP_IMS_5052_01 in CFW step 29B (BYE): 
ensure that { 
when { IMS A receives a BYE from UE B} 
then { IMS_A sends the BYE to IMS_B 
not containing a Route header 

indicating the P-CSCF_SIP_URI of ll\/IS_A and 
containing the same Record-Route_header 
as in the previous ACK 
} 
} 



Step 


Direction 


Message 


Comment 




U 
s 

e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


1 

M 
S 
B 






27B 








^ 










User Bends call 


28B 












>. 




BYE 


UE B releases the call with BYE 




29B 


BYE 


IMS A forwards BYE to IMS B 




30B 


BYE 


IMS B forwards BYE to IMS A 




31 B 
32B 


«— 




«— 
















BYE 


IMS A forwards BYE to UE A 

User A is informed that call has ended 
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4.5.3.1.2.4 



Subsequent target refresh request (INVITE) 



Interoperability Test Description 


Identifier: 


TD IMS CALL 0010 


Summary: 


IMS network handles subsequent INVITEs correctly in case of a user initiated call hold 




and resume when roaming caller puts a home user on hold and resumes call. 


Configuration: 


OF ROAIV 


1 GALL 1 


SUT 


IMS A 1 


References 


Test Purpose 


Specification Reference 


TP IMS 5048 01 


TS 124 229 [1], clause 5.2.6.3 1126 


TP IMS 5080 01 


TS 124 229 [1], clause 5.2.9.1 12 


Use Case ref.: 


UC 03 R 1 


r 


"^ 


^r — ^^^r 


Pre-test 


• HSS of IMS A and of IMS B is configured according to table 1 


conditions: 


UE 


A and UE B have IP bearers established to their respective IMS networks 




as 


Der clause 4.2.1 




UE 


_B configured to perform user initiated hold/resume using INVITE 




UE 


_A registered in IMS_A using any user identity 


^^^^^^_ 


UE 


B is registered in IMS B via IMS A using any user identity 


Test Sequence: 


Step 




1 


User B calls User A 


2 


Verify that user A is informed of incoming call of User B 


3 


Verify that user B is informed that UE A is ringing 


4 


User A answers call 


5 


Verify that user B is informed that call has been answered 


6 


Verify that user A is informed that call is established 


7 


User B puts call on hold 


8 


Verify that user A is informed that call is on hold 


9 


Verify that user B is informed that call is on hold 


10 


User B resumes call 


11 


Verify that user A is informed that call is resumed 


12 


Verify that user B is informed that call is resumed 


13 


User A ends call 


14 


Verify that user B is informed that call has ended 


15 


Verify that user A is informed that call has ended 


1 


^^^H 




Conformance 
Criteria: 


Check 




1 


TP_IMS_5048_01 in CFW step 38B and 57B (INVITE): 






ensure that { 






when { IMS A receives a subsequent INVITE from UE B } 






then { IMS A sends the INVITE to IMS B 






containing a topmost Route header 






not indicating the P-CSCF_SIP_URI of IMS_A and 






containing an additional topmost Record-Route_header 






containing ( the P-CSCF_port_number "where it awaits 






subsequent requests" from UEA and 






(the P-CSCF-FQDN address or 






the P-CSCF-IP_address)) of IMS_A and 






containing an additional Via header 






containing ( the P-CSCF via port number and 






(the P-CSCF-FQDN address or 






the P-CSCF-IP address)) of IMS A } 
} 


2 


TP_IMS_5080_01 in CFW step 38B and 57B (INVITE): 






ensure that { 






when { IMS A receives subsequent INVITE from UE B} 






then { IMS A sends the INVITE to IMS B 






containing a P-Charging-Vector_header 






containing an updated access-network-charging-info_parameter} 
} 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


1 
IVI 

s 

B 






35B 








» 










User B puts call on hold 


36B 






^ 




V 






INVITE 


UE_B sends relNVITE message indicating 
media attribute "sendonly" (Call Hold) 




37B 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




38B 


INVITE 


IMS A forwards INVITE to IMS B 


f 


398 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 




40B 


INVITE 


IMS B forwards INVITE to IMS A 


^ 


41B 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




42B 


INVITE 


IMS A forwards INVITE to UE A 








43B 


100 Trying 


UE_A optionally responds with a 100 Trying 
provisional response 








44B 




d 














User A is informed that call is on hold 


45B 
















200 OK 


UE_A responds to INVITE with 200 OK 
indicating attribute "recvonly" 


^ 




^ 


46B 


200 OK 


IMS A forwards 200 OK response to IMS B 




47B 


200 OK 


IMS B forwards 200 OK response to IMS A 




48B 


200 OK 


IMS A forwards the 200 OK response to UE B 




49B 


ACK 


UE B acknowledges the receipt of 200 OK for 
INVITE 




SOB 


ACK 


IMS A forwards ACK to IMS B 




51 B 


ACK 


IMS B forwards ACK to IMS B 




52B 


ACK 


IMS A forwards ACK to UE A 








53B 








i 










User B is informed that call is on hold 


54B 


» 




User B resumes call 


55B 












V 




INVITE 


UE_B sends relNVITE message indicating 
media attribute "sendrecv" (Call Resume) 




56B 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




57B 


INVITE 


IMS A forwards INVITE to IMS B 




58B 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 


f 


59B 


INVITE 


IMS B forwards INVITE to IMS A 


V 


60B 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




61B 


INVITE 


IMS A forwards INVITE to UE A 






N. 


62B 


100 Trying 


UE_A optionally responds with a 100 Trying 
provisional response 








63B 




i 














User A is informed that call is resumed 



£75/ 



115 



ETSI TS 186 011-2 V2.3.1 (2010-04) 



4.5.3.1.2.5 



Subsequent target refresh request (UPDATE), roaming user initiated 



Interoperability Test Description 


Identifier: 


TD IMS CALL 0011 


Summary: 


IMS network handles subsequent UPDATES correctly in case of a user initiated call 
hold and resume when roaming caller puts a home user on hold and resumes call. 


Configuration: 


OF ROAM GALL 


SUT 


IMS A 


References 


Test Purpose 


Specification Reference 


TP IMS 5080 02 


TS 124 229 [1], clause 5.2.9.1 112 


Use Case ref.: 


UC 03 R 1 




Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UE_B has IP bearers established to their respective IMS networks as per 
clause 4.2.1 

• UE_A registered in IMS_A 

• UE_B configured to perform user initiated hold/resume using UPDATE 

• UE B is registered in IMS B via IMS A 


Test Sequence: 


Step 


^ 


1 


User B calls User A 


2 


Verify that user A is informed of incoming call of User A 


3 


Verify that user B is informed that UE A is ringing 


4 


User A answers call 


5 


Verify that user A is informed that call has been answered 


6 


Verify that user B is informed that call is established 


7 


User B puts call on hold 


8 


Verify that user A is informed that call is on hold 


9 


Verify that user B is informed that call is on hold 


10 


User B resumes call 


11 


Verify that user A is informed that call is resumed 


12 


Verify that user B is informed that call is resumed 


13 


User A ends call 


14 


Verify that user B is informed that call has ended 


15 


Verify that user A is informed that call has ended 


^^^^^^^^^^1 




1 


Conformance 
Criteria: 


Cfieck 




1 


TP_IMS_5080_02 in CFW step 37B and 47B (UPDATE): 
ensure that { 
when { IMS A receives subsequent UPDATE from UE B } 
then { IMS_A sends the UPDATE to IMS_B 
containing a P-Charging-Vector_header 

containing an updated access-networl<-charging-info parameter} 
I 



Step 


Direction 


Message 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


u 

E 
B 


1 

M 
S 
A 


1 

M 
S 
B 






T^R 








N 












36B 












V 




UPDATE 


UE_B sends UPDATE message indicating 
media attribute "sendonly" (Call Hold) 




37B 


UPDATE 


IMS A forwards UPDATE to IMS B 


^ 


38B 


UPDATE 


IMS B forwards UPDATE to IMS A 




39B 


UPDATE 


IMS A forwards UPDATE to UE A 








41 B 




K 








N. 




200 OK 


UE_A responds to UPDATE with 200 OK 
indicating media attribute "recvonly" 








42B 


200 OK 


IMS A forwards 200 OK response to IMS B 




43B 


200 OK 


IMS B forwards 200 OK response to IMS A 




44B 










f 








200 OK 


IMS_A forwards the 200 OK response to UE_B 
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Step 


Direction 


IVIessage 


Comment 




U 
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r 
A 
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E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


1 
IVI 

s 

B 






45B 








> 










User B resumes call 


46B 
















UPDATE 


UE_B sends UPDATE message indicating 
media attribute "sendrecv" (Call Resume) 




47B 


UPDATE 


IMS A forwards UPDATE to IIVIS B 


f 


48B 


UPDATE 


IMS B forwards UPDATE to IMS A 




498 


UPDATE 


IMS A forwards UPDATE to UE A 







































4.5.3.1.2.6 



Subsequent target refresh request (UPDATE), home user initiated 



Interoperability Test Description 


Identifier: 


TD IMS CALL 0012 


Summary: 


IMS network handles subsequent UPDATES correctly in case of a user initiated call 
hold and resume when home caller puts a roaming user on hold and resumes call. 


Configuration: 


CF ROAM CALL 


SUT 


IMS A 


References 


Test Purpose 


Specification Reference 


TP IMS 5120 02 


TS 124 229 [1], clause 5.4.3.3 1148 


Use Case ref.: 


UC 03 R J 


Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UEA and UEB have IP bearers established to their respective IMS networks 
as per clause 4.2.1 

• UE_A configured to perform user initiated hold/resume using UPDATE 

• UE_A registered in IMS_A using any user identity 

• UE_B is registered in IMS_B via IMS_A using any user identity 


Test Sequence: 


Step 


^^^^ 


1 


User A calls User B 


2 


Verify that user B is informed of incoming call of User A 


3 


Verify that user A is informed that UE A is ringing 


4 


User B answers call 


5 


Verify that user A is informed that call has been answered 


6 


Verify that user B is informed that call is established 


7 


User A puts call on hold 


8 


Verify that user B is informed that call is on hold 


9 


Verify that user A is informed that call is on hold 


10 


User A resumes call 


11 


Verify that user B is informed that call is resumed 


12 


Verify that user A is informed that call is resumed 


13 


User A ends call 


14 


Verify that user B is informed that call has ended 


15 


Verify that user A is informed that call has ended 




Conformance 
Criteria: 


Check 




1 


TP_IMS_5120_02 in CFW step 38A and 49A (UPDATE); 
ensure that { 

when { UE A sends an UPDATE toUE Bj 
then { IMS_A receives the UPDATE from IMS_B 
containing a topmost Route_header 

not indicating the S-CSCF_SIP_URI 
containing a Record-Route header 
containing the S-CSCF SIP URI } 

} 



ETSI 



117 



ETSI TS 186 011-2 V2.3.1 (2010-04) 



Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


1 

IVI 

s 

B 






35A 




> 














User A puts call on hold 


36A 










V 




UPDATE 


UE_A sends UPDATE message indicating 
media attribute "sendonly" (Call Hold) 






« 


37A 


UPDATE 


IMS A forwards UPDATE to IMS B 


y 


38A 


UPDATE 


IMS B forwards UPDATE to IIMS A 




39A 


UPDATE 


IMS A forwards UPDATE to UE B 


41A 




« 




K 




V 




200 OK 


UE_B responds to with 200 OK indicating media 
attribute "recvonly" 




42A 


200 OK 


IMS A forwards 200 OK response to IMS B 




43A 


200 OK 


IMS B forwards 200 OK response to IMS A 




44A 
45A 


200 OK 


IMS A forwards the 200 OK response to UE A 
User A is informed that call is on hold 








46A 
47A 




» 






N. 


V 




UPDATE 


User A resumes call 

UE_A sends UPDATE message indicating 

media attribute "sendrecv" (Call Resume) 








48A 


UPDATE 


IMS A forwards UPDATE to IMS B 


y 


4gA 


UPDATE 


IMS B forwards UPDATE tolMS A 




50A 


UPDATE 


IMS A forwards UPDATE to UE B 




52A 








i 




N. 




200 OK 


UE_B responds to UPDATE with 200 OK 
indicating media attribute "sendrecv" 




53A 


200 OK 


IMS A forwards 200 OK response to IMS B 




54A 


200 OK 


IMS B forwards 200 OK response to IMS A 




55A 
56A 


«— 




«— 
















200 OK 


IMS A forwards the 200 OK response to UE A 
User A is informed that call is resumed 



4.5.3.1.2.7 
Void. 



Call CANCEL due to loss of connectivity of calling user during call establishment 



4.5.3.1.3 



Subsequent Request Procedures - Originating Network 



4.5.3.1.3.1 



Call CANCEL by calling user 



Interoperability Test Description | 


Identifier: 


TD IMS CALL 0014 


Summary: 


IMS network handles correctly calling user cancelling call before its establishment. 


Configuration: 


CF INT CALL 


SUT 


IMS A 


References 


Test Purpose 


Specification Reference 


TP IMS 5107 3 


TS 124 229 [1], clause 5.4.3.2 149 


Use Case ref.: 


UC 02 1 1 




Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UE_A and UE_B have IP bearers established to their respective IMS networks 
as per clause 4.2.1 

• UE_A is registered in IMS_A using any user identity 

• UE B is registered in IMS B using any user identity 


^^^ 


Test Sequence: 


Step 




1 


User A calls User B 


2 


Verify that user B is informed of incoming call of User A 


3 


Verify that user A is informed that UE B is ringing 


4 


User A cancels call 


5 


Verify that user B is informed that call has been cancelled 


6 


Verify that user A is informed that call is terminated 
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Conformance 
Criteria: 


Cliecl( 


-J 


1 


TP_IMS_5107_03 in CFW step 16 (CANCEL): 








ensure that { 








when { UE A sends CANCEL to UE Bj 








then { IMS B receives the CANCEL 








not containing Route header 








indicating the S-CSCF SIP URI of IMS A 
} 
} 





Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






1 




» 














User A calls User B 


2 












V 




INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired medias and codecs that 
UE A supports 




3 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




4 


INVITE 


IMS A forwards INVITE to IMS B 


y 


5 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 




6 


INVITE 


IMS B forwards INVITE to UE B 


^ 


7 

Q 


100 Trying 


UE_B optionally responds with a 100 Trying 
provisional response 




9 




d 


^ 


^ 








180 Ringing 


UE_B responds to initial INVITE with 180 
Ringing to indicate that it has started alerting 




10 


180 Ringing 


IMS B forwards 180 Ringing response to 
IMS A 




11 
12 


180 Ringing 


IMS A forwards the 1 80 Ringing response to 

UE A 

User A is informed that UE B is ringing 




13 
14 




» 












CANCEL 


User A cancels the call 

UE A sends a CANCEL to IMS A 


^ 


15 


200 OK 


IMS A responds with a 200 OK to UE A 




16 


CANCEL 


IMS A forwards the CANCEL to IIVIS B 




17 


200 OK 


IMS B responds with a 200 OK to IMS A 




18 


CANCEL 


IMS B forwards the CANCEL to UE B 


i 


19 


200 OK 


UE B responds with a 200 OK to IMS B 


20 












> 






User B is informed that call has been cancelled 


21 






^ 








487 Request 
Terminated 


UEB sends 487 Request Terminated to IMS_B 




22 


ACK 


IMS B responds with ACK to UE B 




23 


487 Request 
Terminated 


IMS B forwards the 487 Request Terminated to 
IMS A 




24 


ACK 


IMS A responds with ACK to IMS B 




25 


487 Request 
Terminated 


IMS A forwards the 487 Request Terminated to 
UE A 




26 


ACK 


UE A responds with ACK to IMS A 




27 




i 














User A is informed that call is terminated 



4.5.3.1.3.2 



Call CANCEL due to loss of connectivity of calling user during call 



Interoperability Test Description | 


Identifier: 


TD IMS CALL 0015 


Summary: 


IMS network ends call in case calling UE looses connectivity during a call. 


Configuration: 


CF INT CALL 


SUT 


IMS B 


References 


Test Purpose Specification Reference 
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Interoperability Test Description 




TP IMS 5073 01 Its 124 229 [1], clause 5.2.8.1.2 111 


Use Case ref.: 


UC 02 1 


Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UEA and UEB have IP bearers established to their respective IMS networks 
as per clause 4.2.1 

• UE_A is registered in IMS_A using any user identity 

• UE_B is registered in IMS_B using any user identity 

• IMS_B is supporting (simulated) PDF or PCRF like functionality 






Test Sequence: 


Step 


^ 


1 


User B calls User A 


2 


Verify that user A is informed of incoming call of User B 


3 


Verify that user B is informed that UE A is ringing 


4 


User A answers call 


5 


Verify that user B is presented that call in process 


6 


Verify that user A is informed that the call is in progress 


7 


UE B looses connectivity 


8 


Verify that user A is informed that call has been ended 


^^^^~ 


Conformance 
Criteria: 


Check 




1 


TP_IMS_5073_01 in CFW step 23 (BYE): 
ensure that { 
when { IMS B receives "an indication that UE B is no longer available"} 
then { IMS_B sends a BYE to IMS_A 
containing Request_URI 

indicating the Contact_header_value of UEA and 
containing To_header 

indicating the initial 200_OK_To_value from UEA 
containing From_header 

indicating the initial INVITEFromvalue from UEB and 
containing Call-ID_header 

indicating the initial INVITE_Call_ld_value from UEB and 
containing CSeq_header 

indicating an incremented Sequence_Number and 
containing Route_header 

indicating "dialog specific routing information for UEA" and 
containing Reason_header 

indicating "503 Service Unavailable" and 
containing 

"further headers based on local policy or call release reason" 
} 
} 



Step 


Direction 


Message 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






13 




» 














User A answers call 


14 










> 






200 OK 


UE_A responds INVITE with 200 OK to indicate 
that the call has been answered 




15 


200 OK 


IMS A forwards 200 OK response to IMS B 




16 

H "7 


200 OK 


IMS B forwards the 200 OK response to UE B 


18 






« 


^ 




^ 




ACK 


User B is presented that call in process 

UE B acknowledges the receipt of 200 OK for 

INVITE 




19 


ACK 


IMS B forwards ACK to IMS A 




20 


ACK 


IMS A forwards ACK to UE A 


21 
22 




i 














User A is informed that the call is in progress 
UE B looses connectivity 


23 






^ 










BYE 


IMS B forwards BYE to IMS A 




24 
25 


BYE 


IMS A forwards BYE to UE A 

User A is informed that call has ended 


«— 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






26 
















200 OK 


UE A sends 200 OK for BYE 




27 


200 OK 


IMS A forwards 200 OK response to IMS B 

















4.5.3.1.3.3 



Call failure due to de-registration of calling user during call 



Interoperability Test Description 


Identifier: 


ID IMS CALL 0016 


Summary: 


IMS network ends call in case calling UE is forcefully de-registered in IMS network during 
a call. 


Configuration: 


CF INT CALL 


SUT 


IMS A 


References 


Test Purpose 


Specification Reference 


TP IMS 5139 01 


TS 1 24 229 [1], clause 5.4.5.1 .2 HI 


Use Case ref.: 


UC 02 1 


Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UE_A and UE_B have IP bearers established to their respective IMS networks as 
per clause 4.2.1 

• UE_A is registered in IMS_A using any user identity 

• UE_B is registered in IMS_B using any user identity 

• There is an ongoing dialogue between UE A and UE B 






Test Sequence: 


Step 




1 


User A calls User B 


2 


Verify that user B is informed of incoming call of User A 


3 


Verify that user A is informed that UE B is ringing 


4 


User B answers call 


5 


Verify that User A is informed that call has been answered 


6 


Verify that User B is informed that the call is established 


7 


UE A is forced to be de-registered in IMS A 


8 


Verify that user B is informed that call has been ended 


^^ft ^^ 


Conformance 
Criteria: 


Check 




1 


TP_IMS_5139_01 in CFW step 23 (BYE): 

ensure that { 

when { IMS_A receives a "network internal indication that the lifetime 

of the last public user identity has expired"} 
then { IMS_A sends a BYE to UE_B 

containing a Request_URI set to Contact_header_value of UEB and 
containing a To_header set to 

the To_header of the 200_response to initial INVITE and 
containing a From_header set to 

the From_header of the initial INVITE and 
containing a Call-ID header set to 

the Call-ID_header of the initial INVITE and 
containing a CSeq_header set to 

"CSeq_header from the calling user incremented by one" and 
containing a Route_header set to 
"routeing information towards the called user as stored 
for the dialog" and 
containing a Reasonheader and 
containing "further headers, based on local policy or the 
requested session release reason" 
} 
} 



ETSI 



121 



ETSI TS 186 011-2 V2.3.1 (2010-04) 



Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


u 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






13 












« 






User B answers call 


14 






k 




f 






200 OK 


UE_B responds INVITE with 200 OK to indicate 
that the call has been answered 




15 


200 OK 


IMS B forwards 200 OK response to IMS A 




16 

H -7 


200 OK 


IMS A forwards the 200 OK response to UE A 


18 




K 




V 


> 






ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 




19 


ACK 


IMS A forwards ACK to IMS B 
S-CSCF 




20 


ACK 


IMS B forwards ACK to UE B 


21 
22 












» 






User B is informed that the call is established 
UE A is forced to be de-registered in IMS A 


23 










> 






BYE 


IMS A forwards BYE to IIVIS B 




24 


BYE 


IMS B forwards BYE to UE B 


26 








^ 


^ 


? 




200 OK 


UE B sends 200 OK for BYE 




27 


200 OK 


IMS_B forwards 200 OK response to IMS_A 





















4.5.3.1.3.4 



Subsequent target refresh request (INVITE) 



Interoperability Test Description 


Identifier: 


TD IMS CALL 0017 


Summary: 


IMS network handles subsequent INVITEs correctly in case of a user initiated call hold 
and resume when home caller puts another home user on hold and resumes call. 


Configuration: 


CF INT CALL 


SUT 


IMS A 


References 


Test Purpose 


Specification Reference 


TP IMS 5106 01 


TS 124 229 [1], clause 5.4.3.2 1142 


TP IMS 5121 02 


TS 124 229 [1], clause 5.4.3.3 153 


Use Case ret.: 


UC_03_I I 


Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UE_A and UE_B have IP bearers established to their respective IMS networks 
as per clause 4.2.1 

• UE_A configured to perform user initiated hold/resume using INVITE 

• UEA is registered in IMS_A using any user identity 

• UE B is registered in IMS B using any user identity 


\ 


^^^^ 


Test Sequence: 


Step 




1 


User A calls User B 


2 


Verify that user B is informed of incoming call of User A 


3 


Verify that user A is informed that UE A is ringing 


4 


User B answers call 


5 


Verify that user A is informed that call has been answered 


6 


Verify that user B is informed that call is established 


7 


User A puts call on hold 


8 


Verify that user B is informed that call is on hold 


9 


Verify that user A is informed that call is on hold 


10 


User A resumes call 


11 


Verify that user B is informed that call is resumed 


12 


Verify that user A is informed that call is resumed 


13 


User A ends call 


14 


Verify that user B is informed that call has ended 


15 


Verify that user A is informed that call has ended 
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Interoperability Test Description 



Conformance 
Criteria: 



Check 



TP_IMS_5106_01 in CFW step 25A and 40A (INVITE); 
ensure that { 
when { UEA sends a subsequent INVITE to UEB } 
then { IMS_B receives the subsequent INVITE 
containing a Record-Route_header 

indicating the S-CSCF_SIP_URI of IMS_A and 
containing a Route_header 

not indicating the S-CSCF_SIP_URI of /MS_/\ and 
containing a P-Charging-Vector_header 

not containing an access-network-charging-info_parameter 
} 
1 



TP_IMS_5121_02 (IMS_B) in CFW step 31 A and 46A (200 OK): 
ensure that { 
when { UEB sends a 2xx_response to UEA } 
then { IMS_A receives the 2xx_response 

containing a P-Charging-Vector_header 
not containing a access-network-charging-info_parameter} 
} 



Step 


Direction 


Message 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 

S 
B 


u 

E 
B 


U 
s 
e 
r 
B 






22A 




» 














User A puts call on hold 


23A 
















INVITE 


UE_A sends relNVITE message indicating 
media attribute "sendonly" (Call Hold) 


^ 


24A 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




25A 


INVITE 


IMS A forwards INVITE to IMS B 


^ 


26A 


100 Trying 


IMS_B responds with a 100 Trying 
provisional response 




27A 


INVITE 


IMS B forwards INVITE to UE B 




28A 


100 Trying 


UE_B optionally responds with a 100 Trying 
provisional response 




29A 
30A 








^ 




^ 




200 OK 


User B is informed that call is on hold 
UE_B responds to INVITE with 200 OK 
indicating media attribute "recvonly" 




31 A 


200 OK 


IMS_B forwards 200 OK response to IMS_A 




32A 


200 OK 


IIVIS A forwards the 200 OK response to UE A 




34A 
















ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 




35A 


ACK 


IMS A forwards ACK to IMS B 




36A 

'^7A 


ACK 


IMS B forwards ACK to UE B 




38A 
















INVITE 


UE_A sends relNVITE message indicating 
media attribute "sendrecv" (Call Resume) 




39A 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




40A 


INVITE 


IMS A forwards INVITE to IMS B 




41 A 


100 Trying 


IMS_B responds with a 100 Trying 
provisional response 




42A 


INVITE 


IMS B forwards INVITE to UE B 


^ 


43A 


100 Trying 


UE_B optionally responds with a 100 Trying 
provisional response 




44A 












» 






User B is informed that call is resumed 


45A 








^ 


^ 






200 OK 


UE_B responds to INVITE with 200 OK 
indicating media attribute "sendrecv" 




46A 


200 OK 


IMS_B forwards 200 OK response to IMS_A 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






47A 
48A 
















200 OK 


IMS_A forwards the 200 OK response to UE_A 
User A is informed that call is resumed 





















4.5.3.1.3.5 



Subsequent target refresh request (UPDATE) 



Interoperability Test Description 


Identifier: 


TD IIVIS CALL 0018 


Summary: 


IMS network handles subsequent UPDATES correctly in case of a user initiated call 
hold and resume when home caller puts another home user on hold and resumes call. 


Configuration: 


OF INT GALL 


SUT 


IMS A, IMS B 


References 


Test Purpose 


Specification Reference 


TP IMS 5106 02 


TS 124 229 [1], clause 5.4.3.2 1142 


TP IMS 5121 02 


TS 124 229 [1], clause 5.4.3.3 1153 


Use Case ref.i 


UC 03 1 


^^^ 


Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UE_A and UE_B have IP bearers established to their respective IMS networks 
as per clause 4.2.1 

• UE_A configured to perform user initiated hold/resume using UPDATE 

• UE_A is registered in IMS_A using any user identity 

• UE B is registered in IMS B using any user identity 


Test Sequence: 


Step 




1 


User A calls User B 


2 


Verify that user B is informed of incoming call of User A 


3 


Verify that user A is informed that UE A is ringing 


4 


User B answers call 


5 


Verify that user A is informed that call has been answered 


6 


Verify that user B is informed that call is established 


7 


User A puts call on hold 


8 


Verify that user B is informed that call is on hold 


9 


Verify that user A is informed that call is on hold 


10 


User A resumes call 


11 


Verify that user B is informed that call is resumed 


12 


Verify that user A is informed that call is resumed 


13 


User A ends call 


14 


Verify that user B is informed that call has ended 


15 


Verify that user A is informed that call has ended 


^1 '^H 




Conformance 
Criteria: 


Check 




1 


TP_IMS_51 06_02 (IMS_A) in GFW step 24A and 33A (UPDATE): 
ensure that { 
when { UE A sends an UPDATE to UE B} 
then { IMS_B receives the UPDATE 

containing a Record-Route_header 

containing the S-CSCF_SIP_URI of IMS_A and 
not containing Route header 

indicating the S-CSCF_SIP_URI of IMS_A and 
containing a P-Charging-Vector_header 
not containing an access-networl<-charging-info parameter 
} 
} 
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Interoperability Test Description 



TP_IMS_5121_02 (IMS_B) in CFW step 28A and 37A (200 OK): 
ensure that { 
when { UEB sends a 2xx_response to UEA } 
then { IMS_A receives the 2xx_response 

containing a P-Charging-Vector_header 
not containing a access-networi<-charging-info_parameter} 
}_ 



Step 


Direction 


Message 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 

s 
e 
r 
B 






22A 




» 














User A puts call on hold 


23A 
















UPDATE 


UE_A sends UPDATE message indicating 
media attribute "sendonly" (Call Hold) 




24A 


UPDATE 


IMS A forwards UPDATE to IMS B 




25A 

OCA 


UPDATE 


IMS B forwards UPDATE to UE B 




27A 






^ 


^ 




7 




200 OK 


UE_B responds to UPDATE with 200 OK 
indicating media attribute "recvonly" 




28A 


200 OK 


IMS_B forwards 200 OK response to IMS_A 




29A 


200 OK 


IMS A P-CSCF forwards the 200 OK response 
toUE A 




30A 
31A 




« 

» 














User A Is informed that call is on hold 
User A resumes call 


32A 










^ 






UPDATE 


UE_A sends UPDATE message indicating 
media attribute "sendrecv" (Call Resume) 




33A 


UPDATE 


IMS A forwards UPDATE to IMS B 




34A 


UPDATE 


IMS B forwards UPDATE to UE B 


OOA 

36A 








^ 




7 




200 OK 


UE_B responds to UPDATE with 200 OK 
indicating media attribute "sendrecv" 




37A 


200 OK 


IMS_B forwards 200 OK response to IMS_A 




38A 


200 OK 


IMS A forwards the 200 OK response to UE A 




39A 




« 














User A is informed that call is resumed 



4.5.3.1.3.6 



Addition of media streams (relNVITE) 



Pre-test 
conditions: 



Interoperability Test Description 


Identifier: 


TD IMS CALL 0019 


Summary: 


IMS network handles subsequent INVITEs correctly when adding new media stream. 


Configuration: 


CF INT CALL 


SUT 


IMS A 


References 


Test Purpose 


Specification Reference 


TP IMS 5106 01 


TS 124 229 [1], clause 5.4.3.2 142 


TP IMS 5121 01 


TS 124 229 [1], clause 5.4.3.3 1175 


TP IMS 5121 02 


TS 124 229 [1], clause 5.4.3.3 1175 


Use Case ref.: 


UC 13 


^^^^^^^^^^^^^1 







HSS of IMS_A and of IMS B is configured according to table 1 

UE_A and UE_B have IP bearers established to their respective IMS networks 

as per clause 4.2.1 

UE_A and UE_B support multiple media streams (eg. audio, video, messaging) 

and support RTP and MSRP 

UE_A is registered in IMS_A using any user identity 

UEB is registered in IMS_B using any user identity 



Test Sequence: 



Step 



User A calls User B (IMS VoIP call 



Verify that User B is informed of incoming call of User A 
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Interoperability Test Description 




3 


Verify that User A is informed tliat UE A is ringing 


4 


User B answers tlie call 


5 


Verify that User A is informed that call has been answered 


6 


Verify that User B is informed that call is established 


7 


User A adds a new media stream 


8 


Verify that User B is informed to accept new media stream (optional) 


9 


Verify that User A is informed to accept new media stream (optional) 


10 


If informed, User B accepts the new media stream 


11 


Verify that User A is informed that new media stream has been accepted 


12 


User A releases the call 


13 


Verify that user B is informed that call has ended 


14 


Verify that user A is informed that call has ended 




^ ^^^^d 


Conformance 
Criteria: 


Check 




1 


TP_IMS_5106_01 in CFW step 25A: 
ensure that { 
when { UEA sends a subsequent INVITE to UEB } 
then { IMS_B receives the subsequent INVITE 
containing a Record-Route header 

indicating the S-CSCF_SIP_URI of IMS_A and 
containing a Route_header 

not indicating the S-CSCF_SIP_URI of IMS_A and 
containing a P-Charging-Vector_header 
not containing a access-network-charging-info parameter} 
} 


2 


TP_IMS_5121_01 in CFW step 26A, 31 A (180 ringing): 
ensure that { 
when { UEB sends a 1xx response to UEA } 
then { IMS_A receives the 1xx response 

containing a P-Charging-Vector_header 
not containing a access-network-charging-info jiarameterj 
} 


3 


TP_IMS_5121_02 in CFW step 36A, 48 (200 OK): 
ensure that { 
when { UEB sends a 2xx_response to UEA } 
then { IMS_A receives the 2xx_response 

containing a P-Charging-Vector_header 
not containing a access-network-charging-info jiarameterj 

} 



Step 


Direction 


lUlessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






22A 
23A 




? 




>. 








INVITE 


User A adds a new media stream 

UE_A sends relNVITE message with new media 

stream in SDP 




24A 


100 Trying 


IIVIS_A responds with a 100 Trying provisional 
response 




25A 


INVITE 


IMS A forwards tlie INVITE to IMS B 


^ 


26A 


100 Trying 


IMS_B responds with a 100 Trying 
provisional response 




27A 


INVITE 


IMS B forwards INVITE to UE B 


^ 


28A 


100 Trying 


UE_B optionally responds with a 100 Trying 
provisional response 




29A 


















Verify that User B is informed to accept/reject 
new media stream (optional) 




30A 






y 


^ 








180 Ringing 


UE B responds to relNVITE with 180 Ringing 




31 A 


180 Ringing 


IMS B forwards 180 Ringing response to 
IMS A 




32A 


180 Ringing 


IIVIS A forwards the 180 Ringing response to 
UE A 
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Step 


Direction 


Message 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

IVI 

s 

A 


1 

IVI 

s 

B 


u 

E 
B 


U 
s 
e 
r 
B 






33A 












^ 






Verify that User A is informed that UE_B is 
alerting User B (optional) 




34A 




If informed, User B accepts the new media 
stream 




35A 






^ 




^ 






200 OK 


UE B responds with 200 OK to relNVITE 




36A 


200 OK 


IMS B forwards 200 OK response to IMS A 




37A 


200 OK 


IMS A forwards the 200 OK response to UE A 




38A 




^ 














User A is informed that new media stream has 
been accepted 




39A 








V 








ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 




40A 


ACK 


IMS A forwards ACK to IMS B 




41A 


ACK 


IMS B forwards ACK to UE B 




42 




> 












BYE 


User A releases the call 


43 






■N. 


N. 


■N. 






BYE 


UEA sends BYE to indicate that the call has 
ended 




44 


BYE 


IMS A sends a BYE to IMS B 




45 

Aft 


BYE 


IMS_B forwards the BYE response to UE_B 




47 






^ 


^ 


^ 






200 OK 


UE B responds to the BYE with 200 OK 




48 


200 OK 


IMS B forwards the 200 OK response to 
IMS A 




49 
50 


200 OK 


IMS_A forwards the 200 OK response to UE_A 
User A is informed that call has ended 


< — 



















4.5.3.1.3.7 



Modification of an existing media stream (relNVITE) 



Interoperability Test Description 


Identifier: 


TD IMS CALL 0020 


Summary: 


IMS network handles subsequent INVITEs and UPDATES correctly during modification 
of an existing media stream. 




Configuration: 


CF INT CALL 


SUT 


IMS A 


References 


Test Purpose 


Specification Reference 


TP IMS 5106 01 


TS 124 229 [1], clause 5.4.3.2 142 


TP IMS 5121 01 


TS 124 229 [1], clause 5.4.3.3 1175 


TP IMS 5121 02 


TS 124 229 [1], clause 5.4.3.3 1175 


Use Case ref.: 


UC 13 1 


1 ^^^^H 

Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UE_A and UE_B have IP bearers established to their respective IMS networks 
as per clause 4.2.1 

• UE_A and UE_B support multiple media streams (eg. audio, video, messaging) 
and support RTP and MSRP 

• UE_A is registered in IMS_A using any user identity 

• UE B is registered in IMS B using any user identity 


Test Sequence: 


Step 




1 


User A calls User B (IMS VoIP call) 


2 


Verify that user B is informed of incoming call of User A 


3 


Verify that user A is informed that UE B is ringing 


4 


User B answers the call 


5 


Verify that user A is informed that call has been answered 


6 


Verify that user B is informed that call is established 
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Interoperability Test Description 




7 


User A adds a new media stream 


8 


Verify ttiat User B is informed to accept/reject new media stream (optional) 


9 


Verify that User A is informed tliat UE B is alerting User B (optional) 


10 


If informed, verify that User B accepts the new media stream 


11 


Verify that User A is informed that new media stream has been accepted 
(optional) 


12 


User A modifies the media stream 


13 


Verify that User B is informed to accept/reject media stream modification 
(optional) 


14 


Verify that User A is informed that UE B is alerting User B (optional) 


15 


If informed, verify that User B accepts the media stream modification 


16 


Verify that User A is informed that media stream modification has been 
accepted (optional) 


17 


User B releases the call 


18 


User A is informed that the call has ended 


19 


User B is informed that call has ended 


1 1 


Conformance 
Criteria: 


Check 




1 


TP_IMS_5106_01 in CFW step 25A and 45A (relNVITE): 
ensure that { 
when { UEA sends a subsequent INVITE to UEB } 
then { IMS_B receives the subsequent INVITE 
containing a Record-Route header 

indicating the S-CSCF_SIP_URI of IMS_A and 
containing Route header 

not indicating the S-CSCF_SIP_URI of IMS_A and 
containing a P-Charging-Vector_header 
not containing a access-network-charging-info parameter} 
} 


2 


TP_IMS_5121_01 in CFW step 26A, 31 A (180 ringing): 
ensure that { 
when { UEB sends a 1xx response to UEA } 
then { IMS_A receives the 1xx response 

containing a P-Charging-Vector_header 
not containing a access-network-charging-info_parameter} 
} 


3 


TP_IMS_5121_02 in CFW step 36A and 56A (200 OK): 
ensure that { 
when { UEB sends a 2xx_response to UEA } 
then { IMS_A receives the 2xx_response 

containing a P-Charging-Vector_header 
not containing a access-network-charging-info_parameter} 
} 



Step 


Direction 


Message 


Comment 


OOCi 


U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






23A 






N. 










INVITE 


UE_A sends relNVITE message with new 
media stream in SDR 


^ 


24A 


100 Trying 


IIVIS_A responds with a 100 Trying provisional 
response 




25A 


INVITE 


IMS A forwards INVITE to IMS B 




26A 








^ 


V 






100 Trying 


IMS_B responds with a 100 Trying 
provisional response 




27A 


INVITE 


IMS B forwards INVITE to UE B 




28A 


100 Trying 


UE_B optionally responds with a 100 Trying 
provisional response 




29A 












V 






Verify that User B is informed to accept/reject 
new media stream (optional) 




30A 










f 






180 Ringing 


UE B responds to relNVITE with 180 Ringing 
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Step 


Direction 


Message 


Comment 




U 
s 
e 
r 
A 


u 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






31 A 
















180 Ringing 


IMS B forwards 180 Ringing response to 
IMS A 




32A 


180 Ringing 


IMS A forwards the 1 80 Ringing response to 
UE A 




33A 


















Verify that User A is informed that UE_B is 
alerting User B (optional) 








34A 




If informed, verify that User B accepts the new 
media stream 


< 




35A 






^ 




^ 






200 OK 


UE_B responds to relNVITE with 200 OK with 
new media stream (recvonly) 




36A 


200 OK 


IMS B forwards 200 OK response to IMS A 




37A 


200 OK 


IIVIS A forwards the 200 OK response to UE A 




38A 


















Verify that User A is informed that new media 
stream has been accepted (optional) 


i 




39A 








V 


V 






ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 




40A 


ACK 


IMS A forwards ACK to IMS B 




41A 


ACK 


IMS B forwards ACK to UE B 




42A 


















User A modifies the media stream 


> 


43A 






V 










INVITE 


UE_A sends relNVITE message with new 
media stream in SDP 


^ 


44A 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




45A 


INVITE 


IMS A forwards INVITE to IMS B 




46A 


100 Trying 


IMS_B responds with a 100 Trying 
provisional response 




47A 


INVITE 


IMS B forwards INVITE to UE B 




48A 


100 Trying 


UE_B optionally responds with a 100 Trying 
provisional response 




49A 


















Verify that User B is informed to accept/reject 
media stream modification (optional) 


> 




50A 










/ 






180 Ringing 


UE B responds to relNVITE with 180 Ringing 




51 A 


180 Ringing 


IMS B forwards 180 Ringing response to 
IMS A 




52A 


180 Ringing 


IMS A forwards the 1 80 Ringing response to 
UE A 




53A 


















Verify that User A is informed that UEB is 
alerting User B (optional) 








54A 




If informed, verify that User B accepts the 
media stream modification 


< 




55A 






^ 




^ 






200 OK 


UE_B responds to relNVITE with 200 OK with 
new media stream 




56A 


200 OK 


IMS_B forwards 200 OK response to IMS_A 




57A 


200 OK 


IMS A forwards the 200 OK response to UE A 




58A 


















Verify that User A is informed that media 
stream modification has been accepted 
(optional) 


i 




59A 






V 










ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 




60A 


ACK 


IMS A forwards ACK to IMS B 




61A 


ACK 


IMS B forwards ACK to UE B 




62 
















BYE 


User B releases the call 


^ 


63 
















BYE 


UEB releases the call with BYE to IMS B 




64 


BYE 


IMS B forwards BYE to IMS A 




65 


BYE 


IMS A forwards BYE to UE A 




66 




^ 














User A is informed that the call has ended 




67 






N. 


>. 


\ 






200 OK 


UE A sends 200 OK for BYE 




68 


200 OK 


IMS A forwards 200 OK response to IMS B 




69 


200 OK 


IMS B forwards 200 OK to UE B 




70 












> 






User B is informed that call has ended 
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4.5.3.1.3.8 



Hold/resume media streams (relNVITE) 



Interoperability Test Description 


Identifier: 


ID IMS CALL 0021 


Summary: 


IMS network handles subsequent INVITEs correctly during hold/resume of media 
streams. 




Configuration: 


CF INT CALL 


SUT 


IMS A 


References 


Test Purpose 


Specification Reference 


IP IMS 5106 01 


TS 124 229 [1], clause 5.4.3.2 142 


IP IMS 5121 01 


TS 124 229 [1], clause 5.4.3.3 175 


TP IMS 5121 02 


TS 124 229 [1], clause 5.4.3.3 1175 


Use Case ref.: 


UC_13, UCJ4 1 


Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UEA and UEB have IP bearers established to their respective IMS networks 
as per clause 4.2.1 

• UE_A and UE_B support multiple media streams (eg. audio, video, messaging) 
and support RTP and MSRP 

• UE_A is registered in IMS_A using any user identity 

• UE B is registered in IMS B using any user identity 


Test Sequence: 


Step 




1 


User A calls User B (IMS VoIP call) 


2 


Verify that user B is informed of incoming call of User A 


3 


Verify that user A is informed that UE B is ringing 


4 


User B answers the call 


5 


Verify that user A is informed that call has been answered 


6 


Verify that user B is informed that call is established 


7 


User A adds a new media stream 


8 


Verify that User B is informed to accept/reject new media stream (optional) 


9 


Verify that User A is informed that UE_B is alerting User B (optional) 


10 


If informed, verify that User B accepts the new media stream 


11 


Verify that User A is informed that new media stream has been accepted 
(optional) 


12 


User A puts one media stream on hold 


13 


User B is informed that media stream is on hold 


14 


User A is informed that media stream is on hold 


15 


User A resumes the media stream 


16 


User B is informed that the media stream is resumed 


17 


User A is informed that the media stream is resumed 


18 


User A removes one of the media streams 


19 


User B is informed that the media stream has been removed 


20 


User A may be informed that UE_B is alerting User B (optional) 


21 


User A releases the call 




22 


User B is informed that call has ended 


23 


User A is informed that call has ended 


L 1 


Conformance 
Criteria: 


Check 




1 


TP_IMS_5106_01 in CFW step 25A, 45A, 60A, 72A (relNVITE): 
ensure that { 
when { UEA sends a subsequent INVITE to UEB } 
then { IMS_B receives the subsequent INVITE 
containing a Record-Route_header 

indicating the S-CSCF_SIP_URI of IMS_A and 
containing Route header 

not indicating the S-CSCF_SIP_URI of IMS_A and 
containing a P-Charging-Vector_header 
not containing a access-network-charging-info parameter} 
} 
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Interoperability Test Description 




2 


TP_IIVIS_5121_01 in CFW step 31 A, 46A, 61 A, 73A (100 trying), 78A (180 
ringing) 
ensure that { 
when { UEB sends a 1xx response to UEA } 
then { IMS_A receives the 1xx response 

containing a P-Charging-Vector_header 
not containing a access-network-charging-infojDarameter} 
} 


3 


TP_IMS_5121_02 in CFW step 36A, 51A, 66A, 82A (200 OK) 
ensure that { 
when { UEB sends a 2xx_response to UEA } 
then { IMS_A receives the 2xx_response 

containing a P-Charging-Vector_header 
not containing a access-network-charging-infojDarameter} 

} 



Step 


Direction 


Message 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






22A 


















User A adds a new media stream 


> 


23A 
















INVITE 


UE_A sends relNVITE message with new media 
stream in SDP 


y 


24A 


100 Trying 


IIVIS_A responds witli a 100 Trying provisional 
response 




25A 


INVITE 


IMS A forwards INVITE to IMS B 


^ 


26A 


100 
Trying 


IMS_B responds with a 100 Trying provisional 
response 




27A 


INVITE 


IMS B forwards INVITE to UE B 




28A 


100 Trying 


UE_B optionally responds with a 100 Trying 
provisional response 




29A 


















Verify that User B is informed to accept/reject 
new media stream (optional) 


> 




30A 






y 


^ 


^ 






180 
Ringing 


UE_B responds to relNVITE with 180 Ringing 




31 A 


180 
Ringing 


IMS B forwards 180 Ringing response to 
IMS A 




32A 


180 
Ringing 


IIVIS A forwards the 180 Ringing response to 
UE A 




33A 


















Verify that User A is informed that UE_B is 
alerting User B (optional) 








34A 




If informed, verify that User B accepts the new 
media stream 


i 




35A 
















200 OK 


UE_B responds to relNVITE with 200 OK with 
new media stream in SDP (e.g. "m=message 
8700 TCP/MSRP *") 




36A 


200 OK 


IMS B forwards 200 OK response to IMS A 




37A 
















200 OK 


IIVIS A forwards the 200 OK response to UE A 




38A 


















Verify that User A is informed that new media 
stream has been accepted (optional) 


i 




39A 








V 


>. 






ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 




40A 


ACK 


IMS A forwards ACK to IMS B 




41A 


ACK 


IMS B forwards ACK to UE B 




42A 


















User A puts one media stream on hold 


> 


43A 






^ 


V 








INVITE 


UE_A sends relNVITE message indicating media 
attribute "sendonly" (Call Hold) 




44A 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




45A 


INVITE 


IMS A forwards INVITE to IMS B 




46A 


100 
Trying 


IMS_B responds with a 100 Trying provisional 
response 




47A 


INVITE 


IMS B forwards INVITE to UE B 




■' 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 

B 


u 

E 
B 


U 
s 
e 
r 
B 






48A 
















100 Trying 


UE_B optionally responds with a 100 Trying 
provisional response 




49A 












N 






User B is informed that media stream is on hold 




50A 






^ 










200 OK 


UE_B responds to INVITE with 200 OK indicating 
media attribute "recvonly" 




51 A 


200 OK 


IMS B forwards 200 OK response to IMS A 




52A 


200 OK 


IMS A forwards the 200 OK response to UE A 




53A 




^ 














User A is informed that media stream is on hold 




54A 
















ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 




55A 


ACK 


IMS A forwards ACK to IMS B 




56A 


ACK 


IMS B forwards ACK to UE B 




57A 




*. 














User A resumes the media stream 




58A 
















INVITE 


UE_A sends relNVITE message indicating media 
attribute "sendrecv" (Call Resume) 




59A 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




60A 


INVITE 


IMS A forwards INVITE to IMS B 


^ 


61 A 


100 
Trying 


IMS_B responds with a 100 Trying provisional 
response 




62A 


INVITE 


IMS B forwards INVITE to UE B 


^ 


63A 


100 Trying 


UE_B optionally responds with a 100 Trying 
provisional response 




64A 


















User B is informed that the media stream is 
resumed 


> 




65A 






^ 




^ 






200 OK 


UE_B responds to INVITE with 200 OK indicating 
media attribute "sendrecv" 




66A 


200 OK 


IMS B forwards 200 OK response to IMS A 




67A 


200 OK 


IMS A forwards the 200 OK response to UE A 




68A 


















User A is informed that the media stream is 
resumed 


i 




69A 


















User A removes one of the media streams 


> 


70A 








V 








INVITE 


UE A sends relNVITE to IMS A 




71A 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




72A 


INVITE 


IMS A forwards INVITE to IMS B 




73A 


100 
Trying 


IMS_B responds with a 100 Trying provisional 
response 




74A 


INVITE 


IMS B forwards INVITE to UE B 


^ 


75A 


100 Trying 


UE_B optionally responds with a 100 Trying 
provisional response 




76A 


















User B is informed that the chat media stream 
has been removed 


> 




77A 






y 










180 
Ringing 


UE_B optionally responds to relNVITE with 180 
Ringing 




78A 


180 
Ringing 


IMS B forwards 180 Ringing response to 
IMS_A (only if UE_B responds to relNVITE 
with 180 Ringing in 30A) 




79A 


180 
Ringing 


IMS A forwards the 180 Ringing response to 
UE_A (only if UE_B responds to relNVITE with 
180 Ringing in 30A) 




80A 


















User A may be informed that UE_B is alerting 
User B (optional) 


i 




81A 






y 


y 


^ 






200 OK 


UE_B responds to INVITE with 200 OK with SDP 
where the port number for the video stream is set 
to zero (e.g. "m=message TCP/MSRP *") 




82A 


200 OK 


IMS_B forwards 200 OK response to IMS_A 




83A 


200 OK 


IMS A forwards the 200 OK response to UE A 




84A 


ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 




y 
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Step 


Direction 


IVIessage 


Comment 




U 


U 


1 


1 


U 


U 








s 


E 


M 


M 


E 


s 








e 


A 


S 


S 


B 


e 








r 




A 


B 




r 








A 










B 






85A 
















ACK 


IMS A forwards ACK to IMS B 




86A 


ACK 


IMS B forwards ACK to UE B 

















4.5.3.1.3.9 



Hold/resume media streams (UPDATE) 



Interoperability Test Description 


Identifier: 


TD IMS CALL 0022 


Summary: 


IMS network handles subsequent UPDATES correctly during hold/resume of media 
streams. 


^^^^^^^F ^H 


Configuration: 


CF INT CALL 


SUT 


IMS A 


References 


Test Purpose 


Specification Reference 


TP IMS 5106 01 


TS 124 229 [1], clause 5.4.3.2 1142 


TP IMS 5121 02 


TS 124 229 [1], clause 5.4.3.3 1175 


Use Case ref.: 


UC 13, UC 14 1 


Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UEA and UEB have IP bearers established to their respective IMS networks 
as per clause 4.2.1 

• UE_A and UE_B support multiple media streams (eg. audio, video, messaging) 
and support RTP and MSRP 

• UE_A is registered in IMS_A using any user identity 

• UE B is registered in IMS B using any user identity 




Test Sequence: 


Step 




1 


User A calls User B (IMS VoIP call) 


2 


Verify that user B is informed of incoming call of User A 


3 


Verify that user A is informed that UE B is ringing 


4 


User B answers the call 


5 


Verify that user A is informed that call has been answered 


6 


Verify that user B is informed that call is established 


7 


User A adds a new media stream 


8 


Verify that User B is informed to accept/reject new media stream (optional) 


9 


Verify that User A is informed that UE_B is alerting User B (optional) 


10 


If informed, verify that User B accepts the new media stream 


11 


Verify that User A is informed that new media stream has been accepted 
(optional) 


12 


User A puts one media stream on hold 




13 


User B is informed that media stream is on hold 


14 


User A is informed that media stream is on hold 


15 


User A resumes the media stream 


16 


User B is informed that the media stream is resumed 


17 


User A is informed that the media stream is resumed 


18 


User A removes one of the media streams 


19 


User B is informed that the media stream has been removed 


20 


User A releases the call 


21 


UE_B is informed that call has ended 


22 


User A is informed that call has ended 


Conformance 
Criteria: 


Check 




1 


TP_IMS_5106_G2 in CFW step 44A and 53A (UPDATE): 
ensure that { 

when { UE A sends an UPDATE to UE B} 

then { IMS_B receives the UPDATE 

containing a Record-Route header 
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containing ttie S-CSCF_SIP_URI of IMS_A and 
not containing Route lieader 

indicating tlie S-CSCF_SIP_URI of IMS_A and 
containing a P-Ctiarging-Vector_header 

not containing a access-networl<-cfiarging-info parameter} 
} 


2 


TP_IMS_5121_02 (IMS_B) in CFW step 48A, 57A and 66A (200 OK): 
ensure tfiat { 
wlien { UEB sends a 2xx_response to UEA } 
ttien { IMS_A receives ttie 2xx_response 

containing a P-Cfiarging-Vector_fieader 
not containing a access-networl<-cfiarging-infojDarameter} 

} 



Step 


Direction 


Message 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






42A 


















User A puts one media stream on hold 


> 


43A 






N 


V 








UPDATE 


UE_A sends UPDATE message indicating 
media attribute "sendonly" (Call Hold) 




44A 


UPDATE 


IMS A forwards UPDATE to IMS B 




45A 


UPDATE 


IMS B forwards UPDATE to UE B 




46A 












> 






User B is informed that media stream is on hold 


47A 








^ 


^ 






200 OK 


UE_B responds to UPDATE with 200 OK 
indicating media attribute "recvonly" 




48A 


200 OK 


IMS_B forwards 200 OK response to IMS A 




49A 


200 OK 


IMS A P-CSCF forwards the 200 OK response 
toUE A 




50A 




^ 














User A is informed that media stream is on hold 




51A 


















User A resumes the media stream 






52A 






■V 










UPDATE 


UE_A sends UPDATE message indicating 
media attribute "sendrecv" (Call Resume) 




53A 


UPDATE 


IMS A forwards UPDATE to IMS B 




54A 


UPDATE 


IMS B forwards UPDATE to UE B 




55A 


















User B is informed that the media stream is 
resumed 


> 




56A 








^ 








200 OK 


UE_B responds to UPDATE with 200 OK 
indicating media attribute "sendrecv" 




57A 


200 OK 


IMS_B forwards 200 OK response to IMS_A 




58A 


200 OK 


IMS A forwards the 200 OK response to UE A 




59A 


















User A is informed that the media stream is 
resumed 


<i 




60A 


















User A removes one of the media streams 


> 


61A 






■V 


N. 








UPDATE 


UE A sends UPDATE to IMS B 




62A 


UPDATE 


IMS A forwards UPDATE to IMS B 




63A 


UPDATE 


IMS B forwards UPDATE to UE B 




64A 


















User B is informed that the media stream has 
been removed 


> 




65A 








^ 


^ 






200 OK 


UE B responds to INVITE with 200 OK 




66A 


200 OK 


IMS_B forwards 200 OK response to IMS_A 




67A 


200 OK 


IMS A forwards the 200 OK response to UE A 





















4.5.3.1.4 



Subsequent Request Procedures - Terminating Network 



Interoperability Test Description 


Identifier: 


TD IMS CALL 0023 


Summary: 


IMS network ends call in case called UE looses connectivity during a call. 


Configuration: 


CF INT CALL 


SUT 


IMS B 
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Interoperability Test Description 



References 



Test Purpose 



IP IMS 5074 01 



Specification Reference 



TS 124 229 [1], clause 5.2.8.1.2 1111 



Use Case ref.: 

Pre-test 
conditions: 



Test Sequence: 



UC 02 I 



HSS of IMS_A and of IMS B is configured according to table 1 

UE_A and UE_B has IP bearers established to their respective IMS networks as 

per clause 4.2.1 

UE_A is registered in IMS_A using any user identity 

UE_B is registered in IMS_B using any user identity 



Step 



Conformance 
Criteria: 



Check 



User A calls User B 



Verify that user B is informed of incoming call of user A 



Verify that user A is informed that UE_B is ringing 



User B answers call 



Verify that User A is informed that call has been answered 



Verify that User B is informed that the call is established 



UE_B looses connectivity 



Verify that user A is informed that call has been ended 



TP_IMS_5074_01 in CFW step 23 (BYE): 
ensure that { 
when { IMS_B receives 'an indication that UEB is no_longer_avai table' } 
then { IMS_B sends a BYE to IMS_A 
containing Request_URI 

indicating the Contact_header_vaiue of UEA and 
containing To_header 

indicating the initial INVITE_To_vaiue from UEA 
containing From_header 

indicating the initial 200_OK_From_value from UEB and 
containing Call-IDheader 

indicating the initial INVITE_Call_ld_value from UEA and 
containing CSeq_header 

indicating an incremented Sequence_Number and 
containing Route_header 

indicating "dialog specific routing information for UEA" and 
containing Reason_header 

indicating '503 Service Unavailable' and 
"further headers based on local policy or call release reason" 



L 



} 



Step 


Direction 


Message 


Comment 


13 


I 

c 

i 
1 

/ 


J 

1 

i 
V 


L 
E 


J 


c 


A 


C 

E 


1 
> 


L 

E 
E 


J 

i 


I 

E 


J 

► 

r 
3 




IJ^pr R an9wpr<% rail 


14 
















200 OK 


UE_B responds INVITE with 200 OK to indicate 
that the call has been answered 




15 


200 OK 


IMS B forwards 200 OK response to IMS A 




16 

-1 7 


200 OK 


IMS A forwards the 200 OK response to UE A 




18 
















ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 




19 


ACK 


IMS A forwards ACK to IMS B 




20 


ACK 


IMS B forwards ACK to UE B 




21 
22 












^ 






User B is informed that the call is established 
UE B looses connectivity 


23 








^ 








BYE 


IMS B sends a BYE to IMS A 




24 
25 


BYE 


IMS_A forwards the BYE response to UE_A 
UE A is informed that call has ended 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






26 
















200 OK 


UE A responds to the BYE with 200 OK 




27 


200 OK 


IMS A forwards the 200 OK response to IMS B 





















4.5.3.1.5 



Dialogue Procedures - Topology Hiding 



4.5.3.1.5.1 



Normal call 



Interoperability Test Description 


Identifier: 


ID IMS CALL 0024 


Summary: 


IMS network handles basic call with topology hiding correctly. 


Configuration: 


OF INT GALL 


SUT 


IMS A 


References 


Test Purpose 


Specification Reference 


TP IMS 5135 01 


TS 124 229 [1], clause 5.10.4.1 117 


TP IMS 5137 01 


TS 124 229 [1], clause 5.10.4.2 V 


TP IMS 5404 01 


TS 124 229 [1], clause 5.10.2.2 V 


TP IMS 5408 01 


TS 124 229 [1], clause 5.10.2.3 HI 


TP IMS 5408 03 


TS 124 229 [1], clause 5.10.2.3 HI 


TP IMS 5414 01 


TS 124 229 [1], clause 5.10.3.2 V 


TP IMS 5137 02 


TS 124 229 [1], clause 5.10.4.2 V 


TP IMS 5137 03 


TS 124 229 [1], clause 5.10.4.2 V 


Use Case ref.: 

1 ^^^ 


UC 02 1 1 


1 

Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UEA and UEB have IP bearers established to their respective IMS networks 
as per clause 4.2.1 

• UE_A is registered in IMS_A using any user identity 

• UE_B is registered in IMS_B using any user identity 

• IMS A is configured for topology hiding 


1 1 


Test Sequence: 


Step 




1 


User A calls user B 


2 


Verify that user B is informed of incoming call of User A 


3 


Verify that user A is informed that UE B is ringing 


4 


User B answers the call 


5 


Verify that user A is informed that call has been answered 


6 


User B is informed that the call is established 


7 


User A ends the call 


8 


Verify with UE B that call has been released 


9 


Verify with UEA that call has been released 


^F ^^^^ 




Conformance 
Criteria: 


Check 




1 


TP_IMS_5135_01 in CFW step 4 (INVITE): 
ensure that { 
when { UE B sends a initial INVITE to IMS A } 
then { IMS_A sends the initial INVITE to IMS_B 

containing an additional topmost Record-Route header 
indicating the IBCF SIP URI of IMS A } 
} 


2 


TP_IMS_5137_01 in CFW step 4 (INVITE): 
ensure that { 
when { UE A sends an initial INVITE to UE B} 
then { IMS_A sends the INVITE to IMS_B 
containing a Via header 

indicating the IBCF_SIP_URI of IMS_A and 
containing (encrypted_consecutive_header_entries and 
a tol<enized-by_parameter) and 
containing a Record-Route_header 
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Interoperability Test Description 



containing (encrypted_consecutive_lieader_entries and 

a tokenized-by_parameter) and 
containing a Route_lieader 

indicating tiie IBCF_SIP_URI of IMS_A and 
containing (encrypted_consecutive_header_entries and 

a tokenized-by_parameter) } 



TP_IMS_5404_01 in CFW step 4 (INVITE): 
ensure tliat { 
wlien { UE_A sends an initial INVITE to UE_B 

containing a P-Charging-Function-Addresses_header} 
then { IMS_A sends the INVITE 

not containing a P-Charging-Function-Addresses_header} 
1 



TP_IMS_5408_01 in CFW step 19 (ACK): 
ensure that { 
when { UE_A sends an ACK to UE_B } 
then { IMS_A sends the ACK to IMS_B 
containing a Via_header 

indicating the IBCF_SIP_URI of IMS_A and 
containing (encrypted_consecutive_header_entries and 
a tokenized-by_parameter) and 
containing a Route_header 

indicating the IBCF_SIP_URI of IMS_A and 
containing (encrypted_consecutive_header_entries and 
a tokenized-by_parameter) } 
1 



TP_IMS_5408_03 in CFW step 24A (BYE): 
ensure that { 
when { UE_A sends a BYE to UE_B } 
then { IMS_A sends the BYE to IMS_B 
containing a Via_header 

indicating the IBCF_SIP_URI of IMS_A and 
containing (encrypted_consecutive_header_entries and 
a tokenized-by_parameter) and 
containing a Record-Route_header 
containing (encrypted_consecutive_header_entries and 
a tokenized-by_parameter) and 
containing a Route_header 

indicating the IBCF_SIP_URI of IMS_A and 
containing (encrypted_consecutive_header_entries and 
a tokenized-by_parameter) } 
} 



TP_IMS_5414_01 in CFW step 5 (100 Trying): 
ensure that { 

when { UEA sends an initial INVITE to UEB and 
IMS_A sends the INVITE to IMS_B } 

then { IMS_B sends a 100_response to IMS_A } 
I 



TP_IMS_5137_02 in CFW step 10 (180 Ringing): 
ensure that { 
when { UEB sends a 180_response to UEA } 
then { IMS_B sends the 180_response to IMS_A 
containing Via_header 

indicating the IBCF_SIP_URI of IMS_A and 
containing (encrypted_consecutive_header_entries and 
a tokenized-by_parameter) and 
containing Record-Route_header 
containing (encrypted_consecutive_header_entries and 
a tokenized-by_parameter) } 
}_ 



TP_IMS_5137_03 in CFW step 15 and 28A (200 OK): 

ensure that { 
when { UEB sends a 200_response to UEA } 
then { IMS_B sends the 200_response to IMS_A 
containing a Via_header 

indicating the IBCF_SIP_URI of IMS_A and 
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Interoperability Test Description 



containing (encrypted_consecutive_lieader_entries and 

a tokenized-by_parameter) and 
containing a Record-Route_header 
containing (encrypted_consecutive_header_entries and 

a tokenized-by_parameter) } 



Step 


Direction 


Message 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






1 




> 














User A calls User B 


2 
















INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired medias and codecs that 
UE A supports 




3 


100 Trying 


ll\/IS_A responds with a 100 Trying provisional 
response 




4 


INVITE 


IMS A forwards INVITE to IMS B 




5 


100 Trying 


IMS_B responds with a 100 Trying 
provisional response 




6 


INVITE 


IMS B forwards INVITE to UE B 


^ 


7 


100 Trying 


UE_B optionally responds with a 100 Trying 
provisional response 




8 












» 






User B is informed of incoming call of User A 


9 






^ 


^ 


^ 






180 Ringing 


UE_B responds to initial INVITE with 180 
Ringing to indicate that it has started alerting 




10 


180 Ringing 


IMS B forwards 180 Ringing response to 
IMS A 




11 


180 Ringing 


IMS A forwards the 1 80 Ringing response to 
UE A 




12 




« 














User A is informed that UE B is ringing 


13 






User B answers call 


^ 


14 








^ 








200 OK 


UE_B responds INVITE with 200 OK to indicate 
that the call has been answered 




15 


200 OK 


IMS_B forwards 200 OK response to IMS_A 




16 


200 OK 


IMS A forwards the 200 OK response to UE A 




17 




« 














User A is informed that call has been answered 


18 
















ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 




19 


ACK 


IMS A forwards ACK to IMS B 




20 


ACK 


IMS B forwards ACK to UE B 




21 




» 








^ 






User B is informed that the call is established 


22A 






User A ends call 


23A 
















BYE 


UE A releases the call with BYE 




24A 


BYE 


IMS A forwards BYE to IMS B 




25A 


BYE 


IMS B forwards BYE to UE B 




26A 












^ 






User B is informed that call has ended 


27A 






^ 










200 OK 


UE B sends 200 OK for BYE 




28A 


200 OK 


IMS_B forwards 200 OK response to IMS_A 




29A 


200 OK 


IMS_A forwards the 200 OK response to UE_A 




30A 




^ — 
























User A is informed that call has ended 
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4.5.3.1.5.2 



CANCEL call by calling user 



Interoperability Test Description | 


Identifier: 


ID IMS CALL 0025 


Summary: 


IMS network handles calling user cancelling call correctly before its establishment with 




topology hiding. 


Configuration: 


CF INT CALL 


SUT 


IMS A and IMS B 


References 


Test Purpose 


Specification Reference 


IP IMS 5408 02 


TS 124 229 [1], clause 5.10.2.3 V 


Use Case ref.: 


UC 02 1 1 




Pre-test 


• HSS of IMS_A and of IMS B is configured according to table 1 


conditions: 


• UE AandUE B have IP bearers established to their respective IMS networks 




as per clause 4.2.1 




• UE_A is registered in IMS_A using any user identity 




• UE_B is registered in IMS_B using any user identity 




• IMS A is configured for topology hiding 


^ H 


^^^^^^^^^ ^^^^IHH^ ^^ 


Test Sequence: 
1 


Step 




1 


User A calls User B 


2 


Verify that user B is informed of incoming call of User A 


3 


Verify that user A is informed that UE B is ringing 


4 


User A cancels call 


5 


Verify that user B is informed that call has been cancelled 


6 


Verify that user A is informed that call is terminated 


1 

Conformance 
Criteria: 


Clieck 




1 


TP_IMS_5408_02 in CFW step 16 (CANCEL): 






ensure that { 






when { UE A sends a CANCEL toUE Bj 






then { IMS A sends the CANCEL to IMS B 






containing a Via header 






indicating the IBCF_SIP_URI of IMS_A and 






containing (encrypted_consecutive_header_entries and 






a tol<enized-by_parameter) and 






containing a Record-Route_header 






containing (encrypted_consecutive_header_entries and 






a tol<enized-by_parameter) and 






containing a Route header 






indicating the IBCF_SIP_URI of IMS_A and 






containing (encrypted_consecutive_header_entries and 






a tol<enized-by parameter) } 
} 



Step 


Direction 


Message 


Comment 


-1 


U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






2 






V 




V 






INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired medias and codecs that 
UE A supports 


f 


3 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




4 


INVITE 


IMS A forwards INVITE to IMS B 


^ 


5 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 




6 


INVITE 


IMS B forwards INVITE to UE B 




7 


100 Trying 


UE_B optionally responds with a 100 Trying 
provisional response 




8 
9 












^ 




180 Ringing 


User B is informed of incoming call of User A 
UE_B responds to initial INVITE with 180 
Ringing to indicate that it has started alerting 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






10 
















180 Ringing 


IIVIS B forwards 180 Ringing response to 
IMS A 




11 


180 Ringing 


IMS A forwards the 1 80 Ringing response to 
UE A 




12 
13 




« 

» 














User A is informed that UE B is ringing 
User A cancels the call 


14 






V 










CANCEL 


UE A sends a CANCEL to IMS A 


^ 


15 


200 OK 


IMS A responds with 200 OK to UE A 




16 


CANCEL 


IMS A forwards the CANCEL to IIVIS B 


y 


17 


200 OK 


IMS B responds with 200 OK to IMS A 




18 


CANCEL 


IMS B forwards the CANCEL to UE B 




19 


200 OK 


UE B responds with 200 OK to IMS B 




21 






^ 


y 


^ 






487 Request 
Terminated 


UE_B sends 487 Request Terminated to IMS_B 




22 


ACK 


IMS B responds with ACK to UE B 




23 


487 Request 
Terminated 


IMS B forwards the 487 Request Terminated to 
IMS A 




24 


ACK 


IMS A responds with ACK to IMS B 




25 


487 Request 
Terminated 


IMS A forwards the 487 Request Terminated to 
UE A 




26 
27 








-^ 














ACK 


UE A responds with ACK to IMS A 
User A is informed that call is terminated 



4.5.3.1.5.3 



Normal call with hold/resume 



Interoperability Test Description 


Identifier: 


TD IMS CALL 0026 


Summary: 


IMS network handles user initiated call hold and resume correctly when a home caller 
puts a roaming user on hold and resumes call with topology hiding. 


Configuration: 


CF ROAM CALL 


SUT 


IMS A 


References 


Test Purpose 


Specification Reference 


TP IMS 5408 04 


TS 124 229 [1], clause 5.10.2.3 V 


Use Case ref.: 


UC 03 R 1 


1 1 


Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UE_A and UE_B have IP bearers established to their respective IMS networks 
as per clause 4.2.1 

• UE_A configured to perform user initiated hold/resume using INVITE 

• UE_A is registered in IMS_A using any user identity 

• UEB is registered via IMS A in IMS_B using any user identity 

• IMS A is configured for topology hiding 


i 1 


Test Sequence: 


Step 




1 


User A calls User B 


2 


Verify that user B is informed of incoming call of User A 


3 


Verify that user A is informed that UE A is ringing 


4 


User B answers call 


5 


Verify that user A is informed that call has been answered 


6 


Verify that user B is informed that call is established 


7 


User A puts call on hold 


8 


Verify that user B is informed that call is on hold 


9 


Verify that user A is informed that call is on hold 


10 


User A resumes call 




11 


Verify that user B is informed that call is resumed 


12 


Verify that user A is informed that call is resumed 


13 


User A ends call 
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Interoperability Test Description 




14 


Verify that user B is informed that call has ended 


15 


Verify that user A is informed that call has ended 


Conformance 
Criteria: 


Check 


^ 


1 


TP_IMS_5408_04 in CFW step 38A and 57A (INVITE); 
ensure that { 
when { UE A sends a subsequent INVITE to UE B} 
then { IMS_A sends the INVITE to IMS_B 
containing a Via header 

indicating the IBCF_SIP_URI of IMS_A and 
containing (encrypted_consecutive_header_entries and 
a tol<enized-by_parameter) and 
containing a Record-Route_header 
containing (encrypted_consecutive_header_entries and 
a tol<enized-by_parameter) and 
containing a Route header 

indicating the IBCF_SIP_URI of IMS_A and 
containing (encrypted_consecutive_header_entries and 
a tokenized-by parameter) } 
) 



Step 


Direction 


Message 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


1 

M 
S 
B 

1 






34 
35A 




» 




^ 










User B is presented that call is in progress 
User A puts call on hold 


36A 












V 




INVITE 


UE_A sends relNVITE message indicating 
media attribute "sendonly" (Gall Hold) 








37A 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




• 




38A 


INVITE 


IMS A forwards INVITE to IMS B 




39A 


100 Trying 


IIVIS_B responds with a 100 Trying provisional 
response 


^ 


40A 


INVITE 


IMS B forwards INVITE to IMS A 


V 


41A 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




42A 


INVITE 


IMS A forwards INVITE to UE B 


N. 


43A 

AAA 


100 Trying 


UE_B optionally responds with a 100 Trying 
provisional response 




45A 




d 








V 




200 OK 


UE_B responds to INVITE with 200 OK 
indicating media attribute "recvonly" 




46A 


200 OK 


IMS A forwards 200 OK response to IMS B 




47A 


200 OK 


IMS B forwards 200 OK response to IMS A 


V 


48A 


200 OK 


IMS A forwards the 200 OK response to UE A 








49A 


ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 








50A 


ACK 


IMS A forwards ACK to IMS B 




51A 


ACK 


IMS B forwards ACK to IMS A 




52A 
53A 


ACK 


IMS A forwards ACK to UE B 
User A is informed that call is on hold 




54A 
55A 




» 






N. 






INVITE 


User A resumes call 

UE_A sends relNVITE message indicating 

media attribute "sendrecv" (Gall Resume) 


^ 






56A 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 








57A 


INVITE 


IMS A forwards INVITE to IMS B 




58A 












^ 




100 Trying 


IMS_B responds with a 100 Trying provisional 
response 


^ 


59A 




INVITE 


IMS B forwards INVITE to IMS A 




60A 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


1 
IVI 

s 

B 






61A 
















INVITE 


IMS A forwards INVITE to UE B 


V 


62A 


100 Trying 


UE_B optionally responds with a 100 Trying 
provisional response 




63A 




























User B is informed that call is resumed 



4.5.4 Messaging 



4.5.4.1 



Messaging with SIP URI public identities 



Interoperability Test Description 


Identifier: 


TD IMS MESS 0002 


Summary: 


IMS network handles messaging with SIP identity correctly without topology hiding. 


Configuration: 


CF INT CALL 


SUT 


IMS B 


References 


Test Purpose 


Specification Reference 


TP IMS 5097 05 


TS 124 229 [1], clause 5.4.3.2 HI 


TP IMS 5097 06 


TS 124 229 [1], clause 5.4.3.2 HI 


TP IMS 5117 02 


TS 124 229 [1], clause 5.4.3.3 1144 


TP IMS 5118 01 


TS 124 229 [1], clause 5.4.3.3 1145 


Use Case ref.: 


UC 05 1 1 


Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UE_A and UE_B have IP bearers established to their respective IMS networks as 
per clause 4.2.1 




• UEA is registered in IMS_A using userSIP_priv according to table 1 

• UE_B is registered in IMS_B using any user identity 

• IMS A is within the trust domain of IMS B 




• UE_A and UE_B registered with SIP URI public identities 

• IMS A not configured for topology hiding 


.^ 




Test Sequence: 


Step 




1 


User A sends message to user B 


2 


Verify that user B receives message from user A 


^■" T 


■ ^^^^B ^^^^K ^^ 


Conformance 
Criteria: 


Check 




1 


TP_IMS_5097_05 in CFW step 3 (MESSAGE) 
ensure that { 
when { UE_A sends a MESSAGE to UE_B} 
then { IMS_B receives the MESSAGE 
not containing a Route header 

indicating the S-CSCF_SIP_URI of IMS_A 
containing a P-Charging-Vector_header 
(containing an icid_parameter and 
containing a orig-ioi_parameter indicating IMS_A and 
not containing an access-networl<-charging-infoj3arameter and 
not containing a term-ioi parameter) } 
} 




2 


TP_IMS_5097_06 in CFW step 3 (MESSAGE) 
ensure that { 
when { UE A sends a MESSAGE to UE B 

} 
then { IMS_B receives the MESSAGE 

containing a P-Asserted-ldentity header 

indicating the SIP_URI of UE_A and 
containing a P-Asserted-ldentity header 
indicating the Tel URI ofUEAj 

} 






3 


TP IMS 5117 02 in CFW step 7 (200 OK) 
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ensure that { 
when { UEB sends a 2xx_response to UEA } 
then { IMS_A receives the 2xx_response 

containing a P-Charging-Vector_header 
not containing an access-networl<-charging-info parameter} 
} 


4 


TP_IMS_51 1 8_01 in CFW step 7 (200 OK) 
ensure that { 
when { UEB sends 200_response to UEA } 
then { IMS_A receives the 200_response 

containing a P-Charging-Vector_header 
containing a orig-ioi_parameter 

indicating operatorjdentifier of IMS_A and 
containing a term-ioi_parameter 
indicating operator identifier of IMS B} 
} 



Step 


Direction 


Message 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






1 




» 














User A sends an instant message to user B 


2 
















MESSAGE 


UE A sends MESSAGE to IMS A 




3 


MESSAGE 


IMS A sends MESSAGE to IMS B 




4 


MESSAGE 


IMS B sends MESSAGE to UE B 




6 




d 






f 






200 OK 


UE B sends 200 OK to IMS B 




7 


200 OK 


IMS B sends 200 OK to IMS A 




8 
9 


200 OK 


IMS A sends 200 OK to UE A 

Optional: User A is presented a delivery report 









4.5.4.2 



Messaging with TEL URI identities 



Interoperability Test Description 



Identifier: 



ID IMS MESS 0003 



Summary: 



IMS network handles messaging with TEL URI identities correctly. 



Configuration: 



CF INT CALL 



SUT 



IMS B 



References 



Test Purpose 



TP IMS 5097 07 



TP IMS 5117 02 



TP IMS 5118 01 



TP IMS 5117 06 



Specification Reference 



TS 124 229 [1], clause 5.4.3.2 HI 



TS 124 229 [1], clause 5.4.3.3 |44 



TS 124 229 [1], clause 5.4.3.3 1|45 



TS 124 229 [1], clause 5.4.3.3 |44 



Use Case ref.: 

Pre-test 
conditions: 



Test Sequence: 



Conformance 
Criteria: 



UC 05 I 



HSS of IMS_A and of IMS B is configured according to table 1 

UE_A and UE_B have IP bearers established to their respective IMS networks as 

per clause 4.2.1 

UE_A is registered in IMS_A using userTEL_priv according to table 1 

UE_B is registered in IMS_B using userTEL_priv according to table 1 

IMS A is within the trust domain of IMS B 



Step 



User A sends message to User B (i.e. userTEL in IMS_B) 



Verify that user B receives message from user A 



\ 



Check 



TP_IMS_5097_07 in CFW step 3 (MESSAGE) 
ensure that { 
when { UE_A sends a l\/IESSAGE to UE_B 
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} 
then { IMS_B receives the MESSAGE 

containing a P-Asserted-ldentity_header 

indicating the SIP_URI of UE_A and 
containing a P-Asserted-ldentity header 
indicating the Tel URI of UE A } 

} 


2 


TP_IMS_51 17_02 in CFW step 7 (200 OK) 
ensure that { 
when { UEB sends a 2xx_response to UEA } 
then { ll\/IS_A receives the 2xx_response 

containing a P-Charging-Vector_header 
not containing a access-networl<-charging-info_parameter} 

} 


3 


TP_IMS_51 1 8_01 in CFW step 7 (200 OK) 
ensure that { 
when { UEB sends 200_response to UEA } 
then { IMS_A receives the 200_response 

containing a P-Charging-Vector_header 
containing a orig-ioijparameter 

indicating operatorjdentifier of ll\/IS_A and 
containing a term-ioi_parameter 
indicating operator identifier of II^S Bj 
} 


4 


TP_IMS_51 1 7_06 in CFW step 7 (200 OK) 
ensure that { 
when { UE B sends a 2xx response to UE A 

} 
then { IMS_A receives the 2xx_response 

containing a P-Asserted-ldentity header 

indicating the SIP_URI of UE_B and 
containing a P-Asserted-ldentity header 
indicating the Tel URI of UE B} 

} 



Step 


Direction 


Message 


Comment 


1 


U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






2 










» 






MESSAGE 


UE A sends MESSAGE to IMS A 




3 


MESSAGE 


IMS A sends MESSAGE to IMS B 




4 


MESSAGE 


IMS B sends MESSAGE to UE B 


6 






« 


^ 




? 




200 OK 


UE B sends 200 OK to IMS B 




7 


200 OK 


IMS B sends 200 OK to IMS A 




8 


200 OK 


IMS A sends 200 OK to UE A 


9 




i 














Optional: User A is presented a delivery report 



4.5.4.3 



Messaging with DNS/ENUM lookup procedure 



Interoperability Test Description 


Identifier: 


ID IMS MESS 0004 


Summary: 


IMS network handles messaging with DNS/ENUM lookup procedure correctly. 


Configuration: 


CF INT CALL 


SUT 


IMS A 


References 


Test Purpose 


Specification Reference 


IP IMS 5097 08 


TS 124 229 [1], clause 5.4.3.2 HI 


IP IMS 5117 06 


TS 124 229 [1], clause 5.4.3.3 1144 


Use Case ref.: 


UC 05 1 1 
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Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UE_A and UE_B have IP bearers established to their respective IMS networks as 
per clause 4.2.1 

• UE_A is registered in IMS_A using any user identity 

• UE_B is registered in IMS_B using userTEL_priv according to table 1 

• IMS_A is within the trust domain of IMS_B 

• Common DNS is configured with a DNS/ENUM entry mapping 


^^^^^^^^^1 


^^^^^^^^B* '^^ 


Test Sequence: 


Step 




1 


User A sends message to user B's Tel URI (i.e. userTEL in IMS B) 


2 


Verify that user B receives message from user A 


1 1 


Conformance 
Criteria: 


Check 




1 


TP_IMS_5097_08 in GFW step 5 (MESSAGE) 
ensure that { 
when { UE_A sends a MESSAGE to UE_B 
containing a Request_URI 
indicating a Tel URI } 
then { IMS_A sends a DNS_Query to DNS 

containing the Tel_URI_E.164_Number } 
when { IMS_A receives DNS_Response 

containing a NAPTR Resource Record 
indicating the SIP URI of UE Bj 
then { IMS_A sends the MESSAGE to IMS_B 
containing a Request_URI 

indicating a SIP_URI 
containing a P-Charging-Vector_header 
not containing a access-networl<-charging-infoj3arameter} 
} 


2 


TP_IMS_51 1 7_06 in GFW step 9 (200 OK) 
ensure that { 
when { UE B sends a 2xx response to UE A 

} 
then { IMS_A receives the 2xx_response 

containing a P-Asserted-ldentity header 

indicating the SIP_URI of UE_B and 
containing a P-Asserted-ldentity header 
indicating the Tel URI of UE Bj 
} 



Step 


Direction 


Message 


Comment 


-| 


U 
s 
e 
r 
A 


U 

E 
A 

-1 


1 

M 
S 
A 


D 
N 
S 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 




I |c;pr A QpnrI*? an incitpnt mpQ^anp 


2 






\ 












MESSAGE 


UE A sends MESSAGE to IMS A 




3 


DNS QUERY 


IMS_A sends DNS QUERY to common DNS 
containing E.164TELURI 




4 


DNS 
RESPONSE 


Common DNS sends DNS RESPONSE 
containing NAPTR resource record to IMS A 




5 


MESSAGE 


IMS_A sends MESSAGE to IMS_B containing 
Request URI which indicates a SIP URI 






6 


MESSAGE 


IMS B sends MESSAGE to UE B 


8 






i 


/ 




f 






200 OK 


UE B sends 200 OK to IMS B 




9 


200 OK 


IMS B sends 200 OK to IMS A 






10 


200 OK 


IMS A sends 200 OK to UE A 


11 




i 
















Optional; User A is presented a delivery report 
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4.5.4.4 



Messaging when roaming 



Interoperability Test Description 


Identifier: 


ID IMS MESS 0005 


Summary: 


IMS network handles messaging while roaming correctly. 


Configuration: 


OF ROAM CALL 


BUT 


IMS A and IMS B 


References 


Test Purpose 


Specification Reference 


IP IMS 5108 02 


TS 124 229 [1], clause 5.4.3.3 HI 


IP IMS 5118 01 


TS 124 229 [1], clause 5.4.3.3 1145 


Use Case ref.: 


UG 05 R 1 




Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UE_A and UE_B have IP bearers established to their respective IMS networks as 
per clause 4.2.1 

• UE_A is registered in IMS_A using any user identity 

• UE B is registered in IMS B via IMS A using any user identity 


L ^^ ^^^ 


Test Sequence: 


Step 


1 


1 


User A sends message to user B 


2 


Verify that user B receives message from user A 




■" 


Conformance 
Criteria: 


Check 




1 


TP_IMS_5108_02in CFW step 4 (MESSAGE) 
ensure that { 
when { UE A sends a MESSAGE to UE B 
IMS_A sends the MESSAGE to IMS_B 
containing a P-Charging-Vector_header 
containing an icid parameter} 
then { IMS_B sends the MESSAGE to IMS_A 
containing a Route_header 

not indicating the S-CSCF_SIP_URI of IMS_B and 
containing a P-Charging-Vector_header 
containing the same icid_parameter and 
not containing ioi_parameters 
containing a Record-Route header 
containing the S-CSCF SIP URI of IMS B} 
} 


2 


TP_IMS_51 1 8_01 in CFW step 9 (200 OK) 
ensure that { 
when { UEB sends 200_response to UEA } 
then { IMS_A receives the 200_response 

containing a P-Charging-Vectorheader 
containing a orig-ioijparameter 

indicating operatorjdentifier of IMS_A and 
containing a term-ioi_parameter 
indicating operator identifier of IMS B} 

} 



Step 


Direction 


Message 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


1 

M 
S 
B 






1 




^ 














User A sends an instant message to user B 


2 










V 


N. 




MESSAGE 


UE A sends MESSAGE to IMS A 






«— 


/ 


3 


MESSAGE 


IMS A sends MESSAGE to IMS B 




4 


MESSAGE 


IMS B sends MESSAGE to IMS A 




5 


MESSAGE 


IMS A sends MESSAGE to UE B 


6 


















User B is informed about the instant message 


7 










V 


N. 




200 OK 


UE B sends 200 OK to IMS A 




8 


200 OK 


IMS A sends 200 OK to IMS B 




9 


200 OK 


IMS B sends 200 OK to IMS A 




10 






^ 












200 OK 


IMS A sends 200 OK to UE A 
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Step 


Direction 


IVIessage 


Comment 




U 


U 


U 


U 


1 


1 








s 


E 


s 


E 


M 


IVI 








e 


A 


e 


B 


S 


s 








r 




r 




A 


B 






11 


A 


^ 


B 


LJ 


^ 


^ 




Optional: User A is presented a delivery report 



4.5.4.5 



Messaging with receiving user not registered 



Interoperability Test Description 



Identifier: 



TD IIVIS MESS 0006 



Summary: 



IMS network handles messaging correctly when receiving user is not registered. 



Configuration: 



OF INT CALL 



SUT 



IMS B 



References 



Test Purpose 



IP IMS 5114 02 



Specification Reference 



TS 124 229 [1], clause 5.4.3.3 1|34 



Use Case ref.: 



UC 05 I 



Pre-test 
conditions: 



Test Sequence: 



HSS of IMS_A and of IMS B is configured according to table 1 

UE_A and UE_B have IP bearers established to their respective IMS networks as 

per clause 4.2.1 

UE_A is registered in IMS_A using any user identity 

UE_B is nof registered in IMS_B 

IMS_B is nof configured with any filter criteria to contact "any AS" 



Step 



User A sends message to a valid user B identity 



Verify that user A is informed that user B could not be reached 



Conformance 
Criteria: 



Check 



TP_IMS_51 14_02 in CFW step 5 (4xx Response) 
ensure that { 

when { UE_A sends a MESSAGE to UE_B and 
IMS_A sends the MESSAGE to IMS_B } 

then { IMS_B sends a 4xx_response to IMS_A 



L 



} 



Step 


Direction 


Message 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






1 


















User A sends an instant message to NON 
registered user B 




2 






V 










MESSAGE 


UE A sends MESSAGE to IMS A 




3 


MESSAGE 


IMS A sends MESSAGE to IMS B 




4 


















IMS B detects that user B is not registered 


5 






^ 










4xx 
Response 


IMS_B sends 4xx Response to IMS_A 




6 


4xx 
Response 


IMS_A sends 4xx Response to UE_A 




7 












User A is informed that user B could not be 
reached 





















4.5.4.6 



Messaging with receiving user barred 



Interoperability Test Description 


Identifier: 


TD IMS MESS 0007 


Summary: 


IMS network handles messaging correctly when receiving user has been barred. 
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Configuration: 


CF INT CALL 


SUT 


IMS B 


References 


Test Purpose 


Specification Reference 


IP IMS 5108 06 


TS 124 229 [1], clause 5.4.3.3 HI 


Use Case ref.: 


UC 05 1 1 


Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UE_A and UE_B have IP bearers established to their respective IMS networks as 
per clause 4.2.1 

• UE_A is registered in IMS_A using any user identity 

• UE_B is registered in IMS_B using any user identity 

• User B is barred in IMS B 


1 


1 


Test Sequence: 

1 ^ipi^aBl 


Step 




1 


User A sends message to User B 


2 


Verify that user A is informed that user B could not be reached 


Conformance 
Criteria: 


Cliecl< 




1 


TP_IMS_5108_06 in GFW step 5 (404 Response) 
ensure that { 
when { UE A sends a MESSAGE to UE B and 
IMS_A sends the MESSAGE to IMS_B 
containing a Request_URI 

indicating a barred_user in IMS_B } 
then { IMS B sends 404 response to IMS A } 
} 



Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


1 

M 
S 
A 


1 

M 
S 
B 


U 

E 
B 


U 
s 
e 
r 
B 






1 


















User A sends an instant message to registered 
user B 




2 






V 










MESSAGE 


UE A sends MESSAGE to IMS A 




3 


MESSAGE 


IMS A sends MESSAGE to IMS B 




4 


















IMS B detects that user B has been barred 


5 






^ 










404 Not 
Found 


IMS_B sends 404 Response to ll\/IS_A 




6 


404 Note 
Found 


IMS_A sends 404 Response to UE_A 




7 


















Optional: User A is informed that user B could 
not be reached 





















4.5.5 Supplementary Services 



4.5.5.1 



Supplementary Service HOLD with AS 



Interoperability Test Description 


Identifier: 


TD IMS SS 0001 


Summary: 


IMS network supports properly application services based on the example of the HOLD 
supplementary service. 


Configuration: 


OF INT AS 


SUT 


IMS B 


References 


Test Purpose 


Specification Reference 


TP IMS 5310 01 


TS 124 229 [1], clause 5.4.6.1.2 HI 


TP IMS 5312 01 


TS 124 229 [1], clause 5.4.6.1.3 HI 


Use Case ref.: 


UC 10 1 1 
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Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UE_A and UE_B have IP bearers established to their respective IMS networks 
as per clause 4.2.1 

• UE_A is registered in IMS_A using any user identity 

• UE_B is registered in IMS_B using userHOLD identity according to table 1 

• IMS_B is configured to contact AS_B (HOLD) 

• UEB is subscribed to HOLD service 

• AS B in same trust domain as IMS B 


^^^^^^^^^^^ 




Test Sequence: 


Step 


rT» 


1 


User A calls User B (i.e. userHOLD in IMS B) 


2 


Verify that user B is informed of incoming call of User A 


3 


Verify that user A is informed that UE B is ringing 


4 


User B answers call 


5 


Verify that user A is informed that call has been answered 


6 


Verify that user B is informed that call is established 


7 


User B puts call on hold 


8 


Verify that user A is informed that call on hold with AS tone 


9 


Verify that user B is informed that call on hold 


10 


User B resumes call 


11 


Verify that user A is informed that call is resumed 


12 


Verify that user B is informed that call is resumed 


13 


User A ends call 


14 


Verify that user B is informed that call has ended 


15 


Verify that user A is informed that call has ended 


L 1 


Conformance 
Criteria: 


Check 


1 


1 


TP_IMS_5310_01 in CFW step 23 and Step 25 (INVITE) 
ensure that { 
when { UE_B sends a subsequent INVITE to IMS_B 
containing a P-Charging-Vector_header 
containing an access-network-charging-info parameter 

} 
then { IMS_B sends the INVITE to AS_B 

containing a P-Charging-Vector_header 
containing an access-network-charging-info parameter 
} 
} 


2 


TP_IMS_5312_01 in CFW step 35 and Step 36 (200 OK) 
ensure that { 
when { IMS_B receives a 200_response from IMS_A 
containing a P-Charging-Vector_header 

containing an access-network-charging-info parameter 

} 

then { IMS_B sends the 200_response to AS_B 
containing a P-Charging-Vector_header 

containing a access-network-charging-info parameter 

} 
} 




3 


TP_IMS_5310_01 in CFW step 45 and Step 47 (INVITE) 
ensure that { 
when { UE_B sends a subsequent INVITE to IMS_B 
containing a P-Charging-Vector_header 
containing an access-network-charging-info parameter 

} 
then { IMS_B sends the INVITE to AS_B 

containing a P-Charging-Vector_header 
containing an access-network-charging-info parameter 
} 
} 


4 


TP_IMS_5312_01 in CFW step 57 and Step 58 (200 OK) 
ensure that { 
when { IMS_B receives a 200_response from IMS_A 
containing a P-Charging-Vector_header 

containing an access-network-charging-info parameter 
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Interoperability Test Description 



} 

then { IMS_B sends the 200_response to AS_B 
containing a P-Charging-Vector_header 

containing a access-networl<-charging-info_parameter 
} 



} 



Step 


Direction 


Message 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


1 

M 
S 
B 


A 
S 
B 






22 




















User B puts call on hold 




23 






^ 












INVITE 


UEB sends relNVITE message indicating 
media attribute "sendonly" (Call Hold) 


^ 




24 


100 Trying 


IIVIS_B responds with a 100 Trying provisional 
response 






25 


INVITE 


IMS_B sends relNVITE to AS_B 




26 


100 Trying 


AS_B optionally responds with a 100 Trying 
provisional response 


f 


27 


INVITE 


AS_B sends relNVITE to IMS_B 


^ 


28 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 




29 


INVITE 


IMS_B forwards relNVITE to IMS_A 




30 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




31 


INVITE 


IMS_A forwards relNVITE to UE_A 








32 


100 Trying 


UE _A optionally responds with a 1 00 Trying 
provisional response 








33 




















User A is informed that call is on hold with AS 
tone 


i 




34 












N. 






200 OK 


UE_A responds to relNVITE with 200 OK 
indicating media attribute "recvonly" 






^ 


35 


200 OK 


IMS_A forwards 200 OK response to IMS_B 




36 


200 OK 


IMS_B forwards 200 OK response to AS_B 




37 


200 OK 


AS_B forwards 200 OK response to IMS_B 




38 


200 OK 


IMS_A forward the 200 OK to UE_B 






39 




















User B is informed that the call is on hold 


^ 




40 












V 






ACK 


UE B acknowledges the receipt of 200 OK for 
relNVITE 






41 














^ 




ACK 


IMS_B forwards ACK to AS_B 


f 


42 


ACK 


AS_B forwards ACK to IMS_B 




43 


ACK 


IMS_B forwards ACK to UE_B 






44 




















User B resumes call 




45 














X 




INVITE 


UE_B sends second relNVITE message 
indicating media attribute "sendrecv" (Call 
Resume) 






48 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 






47 


INVITE 


IMS_B sends relNVITE to AS_B 




/ 
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Step 


Direction 


Message 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 
IVI 

s 

A 


1 
IVI 

s 

B 


A 
S 
B 






48 












^ 






100 Trying 


AS_B optionally responds with a 100 Trying 
provisional response 




49 


INVITE 


AS_B forwards INVITE to IMS_B 


V 


50 


100 Trying 


IIVIS_B responds with a 100 Trying provisional 
response 




51 


INVITE 


IMS_B sends relNVITE to IMS_A 




52 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




53 


INVITE 


IMS_A forwards relNVITE to UE_A 








54 


100 Trying 


UEA optionally responds with a 100 Trying 
provisional response 








55 




^ 
















User A is informed that call is resumed 




56 


















200 OK 


UEA sends the 200 OK indicating media 
attribute "sendrecv" to IMS A 








57 


200 OK 


ll\/IS_A forwards 200 OK response to IIVIS_B 




58 


200 OK 


ll\/IS_B forwards 200 OK response to AS_B 


f 


59 


200 OK 


AS_B forwards the 200 OK for INVITE 




60 


200 OK 


IMS_B forwards 200 OK to IMS_A 






61 








>■ 












User B is informed that call is resumed 

























4.5.5.2 



Supplementary Service HOLD with AS in roaming 



Interoperability Test Description 


Identifier: 


TD IMS SS 0002 


Summary: 


IMS network supports properly application services based on the example of the HOLD 
supplementary service. 


Configuration: 


CF ROAM AS 


SUT 


IMS B 


References 


Test Purpose 


Specification Reference 


TP IMS 5310 01 


TS 124 229 [1], clause 5.4.6.1.2 HI 


TP IMS 5312 01 


TS 124 229 [1], clause 5.4.6.1.3 HI 


Use Case ref.: 


UC 10 R J 


Pre-test 
conditions: 

^ ' 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UE_A and UE_B have IP bearers established to their respective IMS networks 
as per clause 4.2.1 

• UE_A is registered in IMS_A using any user identity 

• UE B is registered in IMS B via IMS A using userHOLD identity according to 
table 1 

• IMS_B is configured to contact AS_B (HOLD) 

• UEB is subscribed to HOLD service 

• AS B in same trust domain as IMS B 




Test Sequence: 


Step 




1 


User A calls User B (i.e. userHOLD in IMS B) 


2 


Verify that user B is informed of incoming call of User A 


3 


Verify that user A is informed that UE B is ringing 


4 


User B answers call 


5 


Verify that user A is informed that call has been answered 


6 


Verify that user B is informed that call is established 


7 


User B puts call on hold 
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Interoperability Test Description 



10 



11 



12 



13 



14 



15 



Verify that user A is informed that call on hold with AS tone 



Verify that user B is informed that call on hold 



User B resumes call 



Verify that user A is informed that call is resumed 



Verify that user B is informed that call is resumed 



User A ends call 



Verify that user B is informed that call has ended 



Verify that user A is informed that call has ended 



Conformance 
Criteria: 



Check 



TP_IMS_5310_01 in CFW step 28 and Step 32 (INVITE) 
ensure that { 
when { UE_B sends a subsequent INVITE to IMS_B 
containing a P-Charging-Vector_header 
containing an access-network-charging-info_parameter 

} 
then { IMS_B sends the INVITE to AS_B 

containing a P-Charging-Vector_header 
containing an access-network-charging-info_parameter 
} 
I 



TP_IMS_5312_01 in CFW step 42 and Step 43 (200 OK) 
ensure that { 
when { IMS_B receives a 200_response from IMS_A 
containing a P-Charging-Vector_header 

containing an access-network-charging-info_parameter 

} 

then { IMS_B sends the 200_response to AS_B 
containing a P-Charging-Vector_header 

containing a access-network-charging-info_parameter 
} 
I 



TP_IMS_5310_01 in CFW step 55 and Step 59 (INVITE) 
ensure that { 
when { UE_B sends a subsequent INVITE to IMS_B 
containing a P-Charging-Vector_header 
containing an access-network-charging-info_parameter 



} 



then { IMS_B sends the INVITE to AS_B 

containing a P-Charging-Vector_header 
containing an access-network-charging-info_parameter 
} 



L 



TP_IMS_5312_01 in CFW step 69 and Step 70 (200 OK) 
ensure that { 
when { IMS_B receives a 200_response from IMS_A 
containing a P-Charging-Vector_header 

containing an access-network-charging-info_parameter 

} 

then { IMS_B sends the 200_response to AS_B 
containing a P-Charging-Vector_header 

containing a access-network-charging-info_parameter 
} 
I 



Step 


Direction 


Message 


Comment 




U 
s 
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r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


1 

M 
S 
B 


A 
S 
B 






27 




















User B puts call on hold 




28 










^ 








INVITE 


UE B sends relNVITE message indicating 
media attribute "sendonly" (Call Hold) 




/■ 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


u 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 
IVI 

s 

A 


1 

M 
S 
B 


A 
S 
B 






29 














■N. 




100 Trying 


IIVIS_A responds with a 100 Trying provisional 
response 




30 


INVITE 


IMS_A forwards INVITE to IMS_B 


^ 


31 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 


^ 


32 


INVITE 


IIVIS_B sends relNVITE to AS_B 




33 


100 Trying 


AS_B optionally responds with a 100 Trying 
provisional response 




35 


INVITE 


AS_B sends relNVITE to IMS_B 


>. 


35 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 




36 


INVITE 


IMS_B forwards relNVITE to IMS_A 




37 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




38 


INVITE 


IMS_A forwards relNVITE to UE_A 








39 


100 Trying 


UE _A optionally responds with a 1 00 Trying 
provisional response 








40 




















User A is informed that call is on hold with AS 
tone 


i 




41 












V 






200 OK 


UE_A responds to relNVITE with 200 OK 
indicating media attribute "recvonly" 








42 


200 OK 


IIVIS^A forwards 200 OK response to ll\/IS_B 


^ 


43 


200 OK 


ll\/IS_B forwards 200 OK response to AS_B 


^ 


44 


200 OK 


AS_B forwards 200 OK response to ll\/IS_B 




45 


200 OK 


IMS_B forwards 200 OK response to IMS_A 




46 


200 OK 


IMS_A forward the 200 OK to UE_B 




47 








^ 












User B is informed that the call is on hold 




48 














■N. 




ACK 


UE B acknowledges the receipt of 200 OK for 
relNVITE 




49 


ACK 


IMS_A forwards ACK to IMS_B 




50 


ACK 


IMS_B forwards ACK to AS_B 




51 










^ 




f 




ACK 


AS_B forwards ACK to IMS_B 




52 


ACK 


IMS_B forwards ACK to IMS_A 




53 


ACK 


IMS_A forwards ACK to UE_B 




54 




















User B resumes call 




55 














X 




INVITE 


UE B sends second relNVITE message 
indicating media attribute "sendrecv" (Call 
Resume) 




56 


100 Trying 


IIVIS_A responds with a 100 Trying provisional 
response 




57 


INVITE 


IMS_A sends relNVITE to IMS_B 


^ 


58 


100 Trying 


IIVIS_B responds with a 100 Trying provisional 
response 




59 


INVITE 


IIVIS_B sends relNVITE to AS_B 







£75/ 



153 



ETSI TS 186 011-2 V2.3.1 (2010-04) 



Step 


Direction 


Message 


Comment 




U 
s 
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r 
A 
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E 
A 


U 
s 
e 
r 
B 
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E 
B 


1 
IVI 

s 

A 


1 
IVI 

s 

B 


A 
S 
B 






60 












^ 






100 Trying 


AS_B optionally responds with a 100 Trying 
provisional response 




61 


INVITE 


AS_B forwards INVITE to IMS_B 


V 


62 


100 Trying 


IIVIS_B responds with a 100 Trying provisional 
response 




63 


INVITE 


IMS_B sends relNVITE to IMS_A 




64 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




65 


INVITE 


IMS_A forwards relNVITE to UE_A 








66 


100 Trying 


UEA optionally responds with a 100 Trying 
provisional response 








67 




^ 
















User A is informed that call is resumed 




68 


















200 OK 


UEA sends the 200 OK indicating media 
attribute "sendrecv" to IMS A 








69 


200 OK 


ll\/IS_A forwards 200 OK response to IIVIS_B 




70 


200 OK 


ll\/IS_B forwards 200 OK response to AS_B 


f 


71 


200 OK 


AS_B forwards the 200 OK for INVITE 




72 


200 OK 


IMS_B forwards 200 OK to IMS_A 




73 


200 OK 


IMS_A forwards 200 OK to UE_B 




74 




















User B is informed that call is resumed 

























4.5.5.3 



Supplementary Service OIP with AS 



Interoperability Test Description | 


Identifier: 


TD IMS SS 0003 


Summary: 


IMS network supports properly application services based on the example of the OIP 
supplementary service. 


Configuration: 


CF INT AS 


SUT 


IMS A and IMS B 


References 


Test Purpose 


Specification Reference 


TP IMS 5097 02 


TS 124 229 [1], clause 5.4.3.2 HI 


TP IMS 5108 03 


TS 124 229 [1], clause 5.4.3.3 HI 


TP IMS 5115 08 


TS 124 229 [1], clause 5.4.3.3 1165 


Use Case ref.: 


UC_08_I 1 


Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UEA and UEB have IP bearers established to their respective IMS networks 
as per clause 4.2.1 

• UE_A is registered in IMS_A using any user identity 

• UE_B is registered in IMS_B using userOIP identity according to table 1 

• IMS_B is configured to contact AS_B (OIP) 

• UE B is subscribed to OIP service 


1 T 

Test Sequence: 


Step 




1 


User A calls User B (i.e. userOIP in IMS B) 


2 


Verify that user B is informed of incoming call of User A, user A's identity is 
displayed 


3 


Verify that user A is informed that UE B is ringing 


4 


User B answers call 


5 


Verify that user A is informed that call has been answered 
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Interoperability Test Description 




6 


Verify that user B is informed that the call is established 


7 


User A ends call 


8 


Verify that user B is informed that call has ended 


9 


Verify that user A is informed that call has ended 






Conformance 
Criteria: 


Checl< 


^ 


1 


TP_IMS_5097_02 in CFW step 2 & 4 (INVITE) 
ensure that { 
when { IMS A receives an initial INVITE from UE A addressed to UE B 

} 
then { IMS_A sends the initial INVITE to IMS_B 

containing a P-Asserted-ldentity header 

indicating the SIP_URI of UE_A 
and 
containing a P-Asserted- Identity header 

indicating the Tel URI ofUEAj 
} 


2 


TP_IMS_5108_03 in CFW step 4 & 6 (INVITE) 
ensure that { 
when { IMS B receives an initial INVITE from IMS A addressed to UE Bj 
then { IMS_B sends the INVITE to AS_B 
containing a topmost Route_header 

indicating the SIP_URI of AS_B and 
containing a Route header 

indicating the S-CSCF_SIP_URI of IMS_B and 
containing a P-Charging-Vector_header 
including a orig-ioi_parameter 

indicating operatorjdentifier of IMS_A and 
not including a term-ioi parameter} 
} 




3 


TP_IMS_51 1 5_08 in CFW step 22 and 23 (200 OK) 
ensure that { 
when { IMS_B receives 200_response from AS_B addressed to UEA } 
then { IMS_B sends the 200_response to IMS_A 
containing a P-Charging-Vector_header 
including a orig-ioijDarameter 

indicating operatorjdentifier of IMS_A and 
including a term-ioi_parameter 
indicating operator identifier of IMS Bj 

I 



Step 


Direction 


Message 


Comment 


1 


U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


1 

M 
S 
B 


c 
E 


s 
3 




1 Icpr A rall'^ I l9pr R 


2 


















INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired media and codecs that 
UE A supports 


^ 






3 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 








4 


INVITE 


IMS A forwards INVITE to IMS B 




5 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 
























INVITE triggers the OIP IFC in IMS B 


6 










f 




> 




INVITE 


IMS B forwards the INVITE to IMS B AS 


7 


100 Trying 


AS optionally responds with a 100 Trying 
provisional response 




8 


INVITE 


IMS B AS returns, possibly modified, INVITE to 
IMS B 




9 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 




10 


INVITE 


IMS B forwards the INVITE to UE B 
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Step 


Direction 


Message 


Comment 




U 

s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


1 

M 
S 
B 


A 
S 
B 






11 


















100 Trying 


UE_B optionally responds with a 100 Trying 
provisional response 






12 








^ 












User B is informed of incoming call of User A, 
User A's identity is displayed 




13 




« 










V 




180 Ringing 


UE_B responds to initial INVITE with 180 
Ringing to indicate that it has started alerting 




f 


14 


180 Ringing 


IMS B forwards 180 Ringing response to 
IMS_B AS 


^ 


15 


180 Ringing 


IMS B AS forwards 180 Ringing response to 
IMS_B 




16 


180 Ringing 


IMS B forwards the 1 80 Ringing response to 
IMS A 




17 
18 


180 Ringing 


IMS A forwards the 1 80 Ringing response to 

UE A 

User A is informed that UE B is ringing 








19 
20 








^ 






V 




200 OK 


User B answers call 

UE_B responds INVITE with 200 OK to indicate 

that the call has been answered 




^ 


21 


200 OK 


IMS_B forwards 200 OK response to IMS_B AS 




22 


200 OK 


IMS B AS forwards 200 OK response to 
IMS_B 




23 


200 OK 


IMS B forwards the 200 OK response to 
IMS A 




24 


200 OK 


IMS A forwards the 200 OK response to UE A 








25 
































User A is informed that call has been answered 



4.5.5.4 



Supplementary Service OIP with AS in roaming 



Interoperability Test Description 


Identifier: 


TD IMS SS 0004 


Summary: 


IMS network supports properly application services based on the example of the OIP 
supplementary service. 


Configuration: 


CF ROAM AS 


SUT 


IMS A and IMS B 


References 


Test Purpose 


Specification Reference 


TP IMS 5097 02 


TS 124 229 [1], clause 5.4.3.2 HI 


TP IMS 5108 03 


TS 124 229 [1], clause 5.4.3.3 HI 


TP IMS 5115 08 


TS 124 229 [1], clause 5.4.3.3 1165 


Use Case ref.: 


UC 08 R 




Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UE_A and UE_B have IP bearers established to their respective IMS networks 
as per clause 4.2.1 

• UE_A is registered in IMS_A using any user identity 

• UE B is registered in IMS B via IMS A using userOIP identity according to 
table 1 

• IMS_B is configured to contact AS_B (OIP) 

• UE B is subscribed to OIP service 




Test Sequence: 


Step 




1 


User A calls User B (i.e. userOIP in IMS B) 


2 


Verify that user B is informed of incoming call of User A, user A's identity is 
displayed 


3 


Verify that user A is informed that UE B is ringing 


4 


User B answers call 


5 


Verify that user A is informed that call has been answered 


6 


Verify that user B is informed that the call is established 
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Interoperability Test Description 


1 


7 


User A ends call 


8 


Verify that user B is informed that call has ended 


9 


Verify that user A is informed that call has ended 


L 

Conformance 
Criteria: 


Check 




1 


TP_IMS_5097_02 in CFW step 2 & 4 (INVITE) 
ensure that { 
when { IMS A receives an initial INVITE from UE A addressed to UE B 

} 
then { IMS_A sends the initial INVITE to IMS_B 

containing a P-Asserted-ldentity header 

indicating the SIP_URI of UE_A 
and 

containing a P-Asserted-ldentity header 
indicating the Tel URI ofUEAj 

} 


2 


TP_IMS_51 08_03 in CFW step 4 & 6 (INVITE) 
ensure that { 
when { IMS B receives an initial INVITE from IMS A addressed to UE Bj 
then { IMS_B sends the INVITE to AS_B 
containing a topmost Route_header 

indicating the SIP_URI of AS_B and 
containing a Route header 

indicating the S-CSCF_SIP_URI of IUT_ and 
containing a P-Charging-Vector_header 
including a orig-ioi_parameter 

indicating operatorjdentifier of IMS_A and 
not including a term-ioi parameter} 
} 




3 


TP_IMS_51 1 5_08 in CFW step 26 and 27 (200 OK) 
ensure that { 
when { IMS_B receives 200_response from AS_B addressed_to UEA } 
then { IMS_B sends the 200_response to IMS_A 
containing a P-Charging-Vector_header 
including a orig-ioijDarameter 

indicating operatorjdentifier of IMS_A and 
including a term-ioi_parameter 
indicating operator identifier of lUT } 

} 



Step 


Direction 


lUlessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

lUI 
S 
A 


\ 
lUI 

s 

B 


A 
S 
B 






1 




» 
















User A calls User B 


2 


















INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired media and codecs that 
UE_A supports 








3 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 








4 


INVITE 


IMS A forwards INVITE to IMS B 


f 


5 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 
























INVITE triggers the OIP IFC in IMS B 


6 












f 






INVITE 


IMS B forwards the INVITE to IMS B AS 




7 


100 Trying 


AS optionally responds with a 100 Trying 
provisional response 




8 


INVITE 


IMS B AS returns, possibly modified, INVITE to 
IMS B 




9 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 




10 


INVITE 


IMS B forwards the INVITE to IMS A 
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Step 


Direction 


Message 


Comment 




U 
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e 
r 
A 
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E 
A 
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e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


1 

M 
S 
B 


A 
S 
B 






11 










^ 








100 Trying 


ll\/IS_A responds with a 100 Trying provisional 
response 




12 


INVITE 


IMS A forwards the INVITE to UE B 




13 


100 Trying 


UE_B optionally responds with a 100 Trying 
provisional response 




14 




















User B is informed of incoming call of User A, 
User A's identity is displayed 




15 






f 








V 




180 Ringing 


UE_B responds to initial INVITE with 180 
Ringing to indicate that it has started alerting 




16 


180 Ringing 


IMS A forwards 180 Ringing response to 
IMS B 


f 


17 


180 Ringing 


IMS B forwards 180 Ringing response to 
IMS_B AS 




18 


180 Ringing 


IMS B AS forwards 180 Ringing response to 
IMS_B 




19 


180 Ringing 


IMS B forwards the 1 80 Ringing response to 
IMS A 




20 


180 Ringing 


IMS A forwards the 1 80 Ringing response to 
UE A 








21 
22 




« 




^ 












User A is informed that UE B is ringing 
User B answers call 


23 


















200 OK 


UE_B responds INVITE with 200 OK to indicate 
that the call has been answered 




24 


200 OK 


IMS A forwards 200 OK response to IMS B 




25 


200 OK 


IMS_B forwards 200 OK response to IMS_B AS 


f 


26 


200 OK 


IMS B AS forwards 200 OK response to 
IMS_B 




27 






^ 












200 OK 


IMS B forwards the 200 OK response to 
IMS A 




28 


200 OK 


IMS_A forwards the 200 OK response to UE_A 








29 
































User A is informed that call has been answered 



4.5.5.5 



Supplementary Services 01 R and ACR with AS 



Interoperability Test Description 


Identifier: 


TD IMS SS 0005 


Summary: 


IMS network supports properly application services based on the example of the OIR 
and ACR supplementary services. 


Configuration: 


OF INT AS 


SUT 


IMS A and IMS B 


References 


Test Purpose 


Specification Reference 


TP IMS 5108 03 


TS 124 229 [1], clause 5.4.3.3 HI 


TP IMS 5313 01 


TS 124 229 [1], clause 5.4.6.1.3 112 


Use Case ref.: 


UG 06 1 



Pre-test 
conditions: 



HSS of IMS_A and of IMS B is configured according to table 1 

UE_A and UE_B have IP bearers established to their respective IMS networks 

as per clause 4.2.1 

UE_A is registered in IMS_A using userOIR identity according to table 1 

UE_B is registered in IMS_B using any userAGR identity according to table 1 

IMS_A is configured to contact AS_A (OIR) 

UEB is subscribed to ACR service 

IMS_B is configured to contact AS_B (ACR) 



Test Sequence: 



Step 




1 


User A calls User B (i.e. userACR in IMS B) 




2 


Verify that user A is informed that call has been rejected due to ACR 
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Interoperability Test Description 



Conformance 
Criteria: 



Check 



TP_IMS_51 08_03 in CFW step 8 & 10 (INVITE) 
ensure that { 
when { IMS_B receives an initial INVITE from IMS_A addressed_to UEB } 
then { IMS_B sends the initial INVITE to AS_B 
containing a topmost Route_header 

indicating the SIP_URI of AS_B and 
containing a Route_header 

indicating the S-CSCF_SIP_URI of IMS_B and 
containing a P-Charging-Vector_header 
including a orig-ioi_parameter 

indicating operatorjdentifier of IMS_A and 
not including a term-ioi_parameter } 
I 



TP_IMS_5313_01 in CFW step 13 & 14 (433 Anonymity Disallowed) 
ensure that { 
when { IMS_A receives a response from IMS_B 
containing a P-Charging-Vector_header 
including an access-network-charging-info_parameter 

} 

then { IMS_A sends the response to AS_A 

containing a P-Charging-Vector_header 
including an access-network-charging-info_parameter 
} 
I 



Step 


Direction 


Message Comment 


-| 


U 
s 
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E 
A 


U 
s 
e 
r 
B 
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E 
B 


1 

M 
S 
A 
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A 

1 


1 

M 
S 
B 

1 




S 
3 




1 Iqpr A ralk 1 Iqpr R 


2 




















INVITE 


UE_A sends INVITE with the first SDP 
offer indicating all desired media and 
codecs that UE A supports 








3 


100 Trying 


IMS_A responds with a 100 Trying 
provisional response 






























INVITE triggers the OIR IPC in IMS A 


4 




















INVITE 


IMS A forwards the INVITE to IMS A 
AS 




5 


100 Trying 


IMS_A AS optionally responds with a 
100 Trying provisional response 




6 


INVITE 


IMS_A AS returns modified INVITE 
including Privacy header (value "id" or 
"header") to IMS A 




7 


100 Trying 


IMS_A responds with a 100 Trying 
provisional response 




8 


INVITE 


IMS A forwards INVITE to IMS B 


f 




9 


100 Trying 


IMS_B responds with a 100 Trying 
provisional response 




























INVITE triggers the ACR IPC in IMS B 


10 




















INVITE 


IMS B forwards the INVITE to IMS B 
AS 


^ 


11 


100 Trying 


AS optionally responds with a 100 Trying 
provisional response 


^ 


12 


433 

Anonymity 

Disallowed 


IMS_B AS responds with 433 Anonymity 
Disallowed to IMS_B 




13 


433 

Anonymity 

Disallowed 


IMS_B forwards the 433 Anonymity 
Disallowed to IMS_A 
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Step 


Direction 


Message Comment 
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1 

M 
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B 
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S 
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14 




















433 

Anonymity 

Disallowed 


IMS_A forwards the 433 Anonymity 
Disallowed to IMS_A AS 


f 


15 


433 

Anonymity 

Disallowed 


IMS_A AS forwards, possibly modified, 
433 Anonymity Disallowed to IMS_A 




16 


433 

Anonymity 

Disallowed 


ll\/IS_A forwards the 433 Anonymity 
Disallowed to UE_A 








17 




>■ 


















User A is informed that the call has been 
rejected due to ACR 




18 










V 






V 




ACK 


UE A sends ACK to IMS A 








19 


ACK 


IMS A forwards the ACK to IMS A AS 


f 


20 


ACK 


IMS A AS forwards, possibly modified, 
ACK to IMS A 




21 


ACK 


IMS A forwards ACK to IMS B 




22 


ACK 


IMS B forwards ACK to IMS B AS 





























4.5.5.6 



Supplementary Services 01 R and ACR with AS in roaming 



Interoperability Test Description 



Identifier: 



TD IMS SS 0006 



Summary: 



IMS network supports properly application services based on the example of the OIR 
and ACR supplementary services. 



Configuration: 



CF ROAM AS 



SUT 



IMS A and IMS B 



References 



Test Purpose 



IP IMS 5046 01 



IP IMS 5067 01 



IP IMS 5097 09 



Specification Reference 



TS 124 229 [1], clause 5.2.6.3 |5 



TS 124 229 [1], clause 5.2.7.2 117 



TS 124 229 [1], clause 5.4.3.2 fl 



Use Case ref. 



Pre-test 
conditions: 



Test Sequence: 



UC 06 R 



HSS of IMS_A and of IMS B is configured according to table 1 

UEA and UEB have IP bearers established to their respective IMS networks 

as per clause 4.2.1 

UE_A is registered in IMS_A using any userACR identity according to table 1 

UE_B is registered in IMS_B via IMS_A using userOIR identity according to 

table 1 

UE_A is subscribed to ACR service 

IMS_B is configured to contact AS_B (OIR) 

IMS_A is configured to contact AS_A (ACR) 

UE B is subscribed to OIR service 



^^i. 



Step 




1 


User B calls User A (i.e. userACR in IMS B) 


2 


Verify that user B is informed that call has been rejected due to ACR 
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Interoperability Test Description J 




Conformance 
Criteria: 


Check 




1 


TP_IMS_5046_01 in CFW step 2 & 4 (INVITE) 
ensure that { 
when { IMS A receives an initial INVITE from UE B) 
then { IMS_A sends the INVITE to IMS_B 
containing a Route header 

not indicating the P-CSCF_SIP_URI of IMS_A and 
containing a Route_header 
indicating the "list of Service Route header URIs 
from the registration" and 
containing an additional Via_header 
containing ( the P-CSCF via port number and 
(the P-CSCF-FQDN address or 
the P-CSCF-IP_address)) of IMS_A and 
containing an additional topmost Record-Route_header 
indicating (the P-CSCF_port_number 

'where it awaits subsequent requests' from UE A and 
(the P-CSCF-FQDN address or 
the P-CSCF-IP_address)) of IMS_A and 
not containing P-Preferred-ldentity_header and 
containing a P-Asserted-ldentity_header 

containing an address of DEB and 
containing a P-Charging-Vector_header 
containing an icid parameter} 
} 


2 


TP_IMS_5067_01 in CFW step 2 & 4 (INVITE) 
ensure that { 
when { IMS A receives an initial INVITE from UE B} 
then { IMS_A sends the INVITE to IMS_B 

containing a P-Charging-Vector header 
} 
} 




3 


TP_IMS_5097_09 in CFW step 4 & 6 (INVITE) 
ensure that { 
when { IMS B receives an initial INVITE from IMS A addressed to UE A } 
then { IMS_B sends the initial INVITE to AS_B 
containing a Route_header 

indicating the SIP_URI of AS_B and 
containing a P-Charging-Function-Addresses_header and 
containing a P-Charging-Vector_header 
including a orig-ioi_parameter 

indicating operatorjdentifier of IMS_A and 
not including a term-ioi parameter} 
} 



Step 


Direction 


Message Comment 


1 




U 
s 

e 
r 
A 


s 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


A 
S 
A 


1 

M 
S 
B 


i 


s 

3 




1 lc;pr R rallc: 1 Icpr A 


2 




















INVITE 


UE_B sends INVITE with the first SDP 
offer indicating all desired media and 
codecs that UEB supports 




3 


100 Trying 


ll\/IS_A responds with a 100 Trying 
provisional response 




4 


INVITE 


IMS A sends INVITE to IMS B 






5 


100 Trying 


IIVIS_B responds with a 100 Trying 
provisional response 




























INVITE triggers the OIR IFG in IMS B 


6 




















INVITE 


IMS B forwards the INVITE to IMS B 
AS 




7 


100 Trying 


IMS_B AS optionally responds with a 
100 Trying provisional response 
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Step 


Direction 


Message Comment 




U 
s 

6 

r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


A 
S 
A 


1 

M 
S 
B 


A 
S 
B 






8 




















INVITE 


IMS_B AS returns modified INVITE 
including Privacy header (value "id" or 
"header") to IMS B 


V 


9 


100 Trying 


IMS_B responds with a 100 Trying 
provisional response 




10 


INVITE 


IMS B forwards INVITE to IMS A 




N 


11 


100 Trying 


IMS_A responds with a 100 Trying 
provisional response 




























INVITE triggers the ACR IPC in IMS A 


12 




















INVITE 


IMS A forwards the INVITE to IMS A 
AS 


^ 


13 


100 Trying 


AS optionally responds with a 100 Trying 
provisional response 


^ 


14 


433 

Anonymity 

Disallowed 


IMS_A AS responds with 433 Anonymity 
Disallowed to IMS_A 




15 


433 

Anonymity 

Disallowed 


IMS_A forwards the 433 Anonymity 
Disallowed to IMS_B 


^ 




16 


433 

Anonymity 

Disallowed 


IMS_B forwards the 433 Anonymity 
Disallowed to IMS_B AS 


f 


17 


433 

Anonymity 

Disallowed 


IMS_B AS forwards, possibly modified, 
433 Anonymity Disallowed to IMS_B 




18 


433 

Anonymity 

Disallowed 


IMS_B forwards the 433 Anonymity 
Disallowed to IMS_A 






19 


433 

Anonymity 

Disallowed 


IMS_A forwards the 433 Anonymity 
Disallowed to UE_B 




20 






















User B is informed that the call has been 
rejected due to ACR 




21 
















V 




ACK 


UE B sends ACK to IMS A 




22 


ACK 


IMS A sends ACK to IMS B 


^ 




23 


ACK 


IMS B forwards the ACK to IMS B AS 




24 


ACK 


IMS B AS forwards, possibly modified, 
ACK to IMS B 




25 


ACK 


IMS B forwards ACK to IMS A 






26 


ACK 


IMS A forwards ACK to IMS A AS 





























4.5.5.7 



Supplementary Service CFU with AS 



Interoperability Test Description 


Identifier: 


TD IMS SS 0007 


Summary: 


IMS network supports properly application services based on the example of the CPU 
supplementary service. 


Configuration: 


CF INT AS 


SUT 


IMS A and IMS B 


References 


Test Purpose 


Specification Reference 


TP IMS 5097 01 


TS 124 229 [1], clause 5.4.3.2 fl 


TP IMS 5108 03 


TS 124 229 [1], clause 5.4.3.3 fl 


TP IMS 5115 08 


TS 124 229 [1], clause 5.4.3.3 165 


Use Case ref.: 


UC 11 1 
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Interoperability Test Description J 




Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UE_A and UE_B2 have IP bearers established to IMS_B as per clause 4.2.1 

• UE_A is registered in IMS_A using any user identity 

• UE_B2 is registered in ll\yiS_B using any user identity 

• IMS_B is configured to contact AS_B (CPU) for userCPU 

• UE B1 Is subscribed to IMS B and has activated CPU service 


^■~ ^^^^^^^^^^^^^B" ~^^^B~ —^^ 


Test Sequence: 


Step 




1 


User A calls User B (i.e. userCFU in IMS B) 


2 


User A may be informed of call diversion 


3 


User B2 answers call 


4 


Verify that user A is informed that call has been answered 


6 


Verify that user B2 is informed that call is established 


7 


User A ends call 


8 


Verify that user B2 is informed that call has ended 


9 


Verify that user A is informed that call has ended 


^1 ^^ 


Conformance 
Criteria: 


Check 




1 


TP_IMS_5097_01 in CFW step 4 (INVITE): 
ensure that { 

when { UE_A sends an initial INVITE to UE_B } 
then { IMS_B receives the initial INVITE 
not containing a Route header 

indicating the S-CSCF_SIP_URI of IMS_A 
containing a P-Charging-Vector_header 
(containing an icid_parameter and 
containing a orig-ioi_parameter indicating IMS_A and 
not containing an access-network-charging-info_parameter and 
not containing a term-ioi_parameter) and 
containing a Record-Route_header 
indicating the originating S-CSCF SIP URI } 
} 




2 


TP_IMS_5108_03 in CFW step 6 (INVITE) 
ensure that { 
when { IMS B receives an initial INVITE from IMS_A addressed to UE Bj 
then { IMS_B sends the initial INVITE to AS_B 
containing a topmost Route_header 

indicating the SIP_URI of AS_B and 
containing a Route header 

indicating the S-CSCF_SIP_URI of IMS_B and 
containing a P-Charging-Vector_header 
including a orig-ioijparameter 

indicating operatorjdentifier of IMS_A and 
not including a term-ioi parameter} 

} 




3 


TP_IMS_51 1 5_08 in CFW step 20 & 21 (200 OK) 
ensure that { 
when { IMS_B receives 200_response from AS_B addressed_to UEA } 
then { IMS_B sends the 200_response to IMS_A 
containing a P-Charging-Vector_header 
including a orig-ioi_parameter 

indicating operatorjdentifier of IMS_A and 
including a term-ioi_parameter 
indicating operator identifier of IMS BIUT } 

} 



Step 


Direction 


Message 


Comment 


1 


U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B2 


U 
E 
B2 


1 

M 
S 
A 


1 

M 
S 
B 


A 
S 
B 




User A calls User B 
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Step 


Direction IVIessage 


Comment 




U 
s 
e 
r 
A 


u 

E 
A 


U 
s 
e 
r 
B2 


U 
E 
B2 


1 

M 
S 
A 


1 

IVI 

s 

B 


A 
S 
B 






2 










>. 


V 






INVITE 


UE_A sends INVITE with the first SDP 
offer indicating all desired media and 
codecs that UE A supports 


f 






3 


100 Trying 


IMS_A responds with a 100 Trying 
provisional response 








4 


INVITE 


IMS A forwards INVITE to IMS B 




5 


100 Trying 


IMS_B responds with a 100 Trying 
provisional response 
























INVITE triggers the CPU IPC in IMS B 


6 


















INVITE 


IMS B forwards the INVITE to AS B 


^ 


7 


100 Trying 


AS_B optionally responds with the 100 
Trying to IMS B 
























AS B applies the CDIV CPU procedure 


8 






f 






^ 






181 Call is 

being 

forwarded 


AS_B indicates optionally to IMS_B that 
call has been forwarded 




9 


181 Call is 

being 

forwarded 


IMS_B indicates to IMS_A that call has 
been forwarded 




10 


181 Call is 

being 

forwarded 


IMS_A indicates that call to UE_B has 
been forwarded 








11 




i 
















User A may be informed of call diversion 


12 














^ 




INVITE 


AS_B returns modified INVITE including 
new request URI and history header to 
IMS B 


V 


13 


100 Trying 


IMS_B responds with a 100 Trying 
provisional response 




14 


INVITE 


IMS B forwards the INVITE to UE B2 




N. 


15 


100 Trying 


UE_B2 optionally responds with a 100 
Trying provisional response 






16 




















User B2 is informed of incoming call of 
User A 


k 




17 




















User B2 answers call 


^ 


18 






f 












200 OK 


UE_B2 responds to INVITE with 200 OK 
to indicate that the call has been 
answered 




^ 


19 


200 OK 


IMS B forwards 200 OK response to 
AS B 


^ 


20 


200 OK 


AS B returns, possibly modified, 200 
OK to IMS B 




21 


200 OK 


IMS B forwards 200 OK response to 
IMS A 




22 


200 OK 


IMS A forwards 200 OK response to 
UE A 








23 




















User A is informed that call has been 
answered 


i 
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4.5.5.8 



Supplementary Service CFU with AS in roaming 



Interoperability Test Description 


Identifier: 


ID IMS SS 0008 


Summary: 


IMS network supports properly application services based on the example of the CFU 
supplementary service. 


Configuration: 


CF ROAM AS 


SUT 


IMS A and IMS B 


References 


Test Purpose 


Specification Reference 


IP IMS 5046 01 


TS 124 229 [1], clause 5.2.6.3 15 


IP IMS 5067 01 


TS 124 229 [1], clause 5.2.7.2 17 


IP IMS 5070 01 


TS 124 229 [1], clause 5.2.7.3 US 


IP IMS 5110 01 


TS 124 229 [1], clause 5.4.3.3 133 


Use Case ref.: 


UC 11 R 1 


Pre-test 
conditions: 

1 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UE_A and UE_B2 have IP bearers established to IMS_B as per clause 4.2.1 

• UE_A is registered in IMS_A using any user identity 

• UE_B2 is registered in IMS_B via IMS_A using any user identity 

• IMS_A is configured to contact AS_A (CFU) for userCFU 

• UE A1 is subscribed to IMS A and has activated CFU service 


I 

Test Sequence: 


Step 




1 


User B calls User A (i.e. userCFU in IMS A) 


2 


User B may be informed of call diversion 


3 


User A2 answers call 


4 


Verify that user B is informed that call has been answered 


6 


Verify that user A2 is informed that call is established 


7 


User Bends call 


8 


Verify that user A2 is informed that call has ended 


9 


Verify that user B is informed that call has ended 


^V ^^^^ 


" ^^d 


Conformance 
Criteria: 


Check 




1 


TP_IMS_5046_01 in CFW step 4 (INVITE) 
ensure that { 
when { IMS A receives an initial INVITE from UE B} 
then { IMS_A sends the INVITE to IMS_B 
containing a Route header 

not indicating the P-CSCF_SIP_URI of IMS_A and 
containing a Route_header 
indicating the "list of Service Route header URIs 
from the registration" and 
containing an additional Via_header 
containing ( the P-CSCF via port number and 
(the P-CSCF-FQDN address or 
the P-CSCF-IP_address)) of IMS_A and 
containing an additional topmost Record-Route_header 
indicating (the P-CSCF_port_number 

'where it awaits subsequent requests' from UE A and 
(the P-CSCF-FQDN address or 
the P-CSCF-IP_address)) of IMS_A and 
not containing P-Preferred-ldentity_header and 
containing a P-Asserted-ldentity_header 

containing an address of UEB and 
containing a P-Charging-Vector_header 
containing an icid parameter} 
} 


2 


TP_IMS_5067_01 in CFW step 4 (INVITE) 
ensure that { 
when { IMS A receives an initial INVITE from UE B } 
then { IMS_A sends the INVITE to IMS_B 

containing a P-Charging-Vector header 
} 
} 
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Interoperability Test Description 




3 


TP_IMS_5070_01 in CFW step 7 (100 Trying) 

ensure that { 
when { IMS_A receives an initial INVITE from UEB } 
then { IMS A sends a 100 response to IMS B 
} 

} 


4 


TP_IMS_51 1 0_01 in CFW step 23 & 24 (200 OK) 
ensure that { 

when { IMS_A receives a 200_response from AS_A addressed_to UEB } 

then { IMS A sends the 200 response to IMS Bj 

} 



Step 


Direction Message 


Comment 




U 
s 
e 
r 
A2 


u 

E 
A2 


U 
s 
e 
r 
B 


U 

E 
B 


1 

lUI 

s 

A 


1 

M 
S 
B 


A 
S 
A 






1 




















User B calls User A 


^ 


2 










V 








INVITE 


UE_B sends INVITE with the first SDP 
offer indicating all desired media and 
codecs that UE B supports 


y 


3 


100 Trying 


ll\/IS_A responds with a 100 Trying 
provisional response 




4 


INVITE 


IMS A forwards INVITE to IMS B 


^ 


5 


100 Trying 


IMS_B responds with a 100 Trying 
provisional response 


^ 


6 


INVITE 


IMS B forwards INVITE to IMS A 




7 


100 Trying 


IMS_A responds with a 100 Trying 
provisional response 
























INVITE triggers the CPU IPC in IMS A 


8 


















INVITE 


IMS A forwards the INVITE to IMS A AS 


^ 




9 


100 Trying 


IMS A AS optionally responds with the 
100 Trying to IMS A 


























IMS_A AS applies the CDIV CPU 
procedure 


10 










f 


^ 






181 Call is 

being 

forwarded 


IMS_A AS indicates optionally to IMS_A 
that call has been forwarded 






11 


181 Call is 

being 

forwarded 


IMS_A Indicates to IMS_B that call has 
been forwarded 




12 


181 Call is 

being 

forwarded 


IMS_B indicates to IMS_A that call has 
been forwarded 




13 


181 Call is 

being 

forwarded 


IMS_A indicates to UE_B that call to 
UE_A has been forwarded 




14 








<i 












User B may be informed of call diversion 


15 






^ 












INVITE 


IMS_A AS returns modified INVITE 
including new request URI and history 
header to IMS A 






16 


100 Trying 


IMS_A responds with a 100 Trying 
provisional response 






17 


INVITE 


IMS A forwards the INVITE to UE A2 






V 


18 


100 Trying 


UE_A2 optionally responds with a 100 
Trying provisional response 








19 




















User A2 is informed of incoming call of 
UserB 


i 




20 




User A2 answers call 


> 


21 


















200 OK 


UE_A2 responds to INVITE with 200 OK 
to indicate that the call has been 
answered 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A2 


U 

E 
A2 


U 
s 
e 
r 
B 


U 

E 
B 


1 
lUI 

s 

A 


1 
IVI 

s 

B 


A 
S 
A 






22 














V 




200 OK 


IMS A forwards 200 OK response to 
IMS A AS 


^ 




23 


200 OK 


IIUIS A AS returns, possibly modified, 
200 OK to IIVIS A 






24 


200 OK 


IIVIS A forwards 200 OK response to 
IIUIS B 




25 


200 OK 


IMS B forwards 200 OK response to 
IMS A 




26 


200 OK 


IMS A forwards 200 OK response to 
UE B 






27 








^ 












User B is informed that call has been 
answered 













4.5.5.9 



Supplementary Services 01 P and 01 R with AS 



interoperability Test Description 


Identifier: 


TD IMS SS 0009 


Summary: 


IMS network supports properly application services based on the example of the 01 P 
and 01 R supplementary services. 


Configuration: 


CF INT AS 


SUT 


IMS B 


References 


Test Purpose 


Specification Reference 


IP IMS 5097 01 


TS 124 229 [1], clause 5.4.3.2 HI 


IP IMS 5108 03 


TS 124 229 [1], clause 5.4.3.3 HI 


Use Case ref.: 


UC 09 1 



Pre-test 
conditions: 



HSS of IMS_A and of IMS B is configured according to table 1 

UEA and UEB have IP bearers established to their respective IMS networks 

as per clause 4.2.1 

UEA is registered in IMS_A using userOIR_priv Identity according to table 1 

UE_B is registered in IMS_B using userOIP_priv identity according to table 1 

IMS_A is configured to contact AS_A (01 R) 

UE_A is subscribed to 01 R service 

IMS_B is configured to contact AS_B (01 P) 

UE B is subscribed to 01 P service 



Test Sequence: 



Step 



User A calls User B (i.e. userOIP in IMS_B) 



Verify that user B is informed of incoming call of User A and User A's 
identity is not displayed 



Verify that user A is informed that UE_A is ringing 



User B answers call 



Verify that user A is informed that call has been answered 



Verify that user B is informed that the call is established 



User B ends call 



Verify that user A is informed that call has ended 



Verify that user B is informed that call has ended 
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Interoperability Test Description 



Conformance 
Criteria: 



Check 



TP_IMS_5097_01 in CFW step 8 (INVITE): 
ensure that { 

when { UE_A sends an initial INVITE to UE_B } 
then { IMS_B receives the initial INVITE 
not containing a Route_header 

indicating the S-CSCF_SIP_URI of IMS_A 
containing a P-Charging-Vector_header 
(containing an icid_parameter and 
containing a orig-ioi_parameter indicating IMS_A and 
not containing an access-network-charging-info_parameter and 
not containing a term-ioi_parameter) and 
containing a Record- Route_header 
indicating the originating S-CSCF_SIP_URI } 
} 



TP_IMS_5108_03 in CFW step 10 (INVITE) 
ensure that { 
when {IMS_B receives an initial INVITE from IMS_A addressed_to UEBj 
then {IMS_B sends the INVITE to AS_B 
containing a topmost Route_header 

indicating the SIP_URI of AS_B and 
containing a Route_header 

indicating the S-CSCF_SIP_URI of IMS_B and 
containing a P-Charging-Vector_header 
including a orig-ioi_parameter 

indicating operatorjdentifier of IMS_A and 
not including a term-ioi_parameter } 
1 



Step 


Direction 


Message 


Comment 


i 


U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


A 
S 
A 


1 

M 
S 
B 


/ 
c 

[ 


s 
3 




1 lopr A rallQ 1 Icpr R 


2 




















INVITE 


UE_A sends INVITE with the first SDP offer 
indicating all desired media and codecs that 
UE A supports 


f 






3 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 






























INVITE triggers the OIR IPC in IMS A 


4 












>. 






INVITE 


IMS A forwards the INVITE to IMS A AS 




5 


100 Trying 


IMS_A AS optionally responds with a 100 Trying 
provisional response 




6 


INVITE 


IMS_A AS returns modified INVITE including 
Privacy header (value "id" or "header") to IMS B 


■N. 


7 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




8 


INVITE 


IMS A forwards the INVITE to IMS B 






9 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 




























INVITE triggers the OIP IPC in IMS B 


10 
















> 




INVITE 


IMS B forwards the INVITE to IMS B AS 


11 


100 Trying 


IMS_B AS optionally responds with a 100 Trying 
provisional response 


^ 


12 


INVITE 


IMS_B AS returns modified INVITE including 
modified Prom and P-Asserted headers to 
IMS B 




13 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 




14 


INVITE 


IMS B forwards the INVITE to UE B 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


A 
S 
A 


1 

M 
S 

B 


A 
S 
B 






15 




















100 Trying 


UE_B optionally responds with a 100 Trying 
provisional response 








16 








>■ 














User B is informed of incoming call of User A, 
user A's identity is not displayed 




17 






f 














180 Ringing 


UE_B responds to initial INVITE with 180 
Ringing to indicate that it has started alerting 




^ 




18 


180 Ringing 


IMS B forwards the 180 Ringing to IMS B AS 




19 


180 Ringing 


IMS_B AS forwards, possibly modified, 180 
Ringing to IMS B 




20 


180 Ringing 


IMS B forwards 180 Ringing response to 
IMS A 






21 


180 Ringing 


IMS A forwards 180 Ringing response to 
IMS A AS 


f 


22 


180 Ringing 


IMS_A AS forwards, possibly modified, 180 
Ringing response to IMS A 




23 


180 Ringing 


IMS A forwards the 1 80 Ringing response to 
UE A 








24 
25 




« 




? 














User A is informed that UE B is ringing 
User B answers call 


26 






^ 














200 OK 


UE_B responds INVITE with 200 OK to indicate 
that the call has been answered 




f 




27 


200 OK 


IMS B forwards the 200 OK to IMS B AS 


^ 


28 


200 OK 


IMS B AS forwards, possibly modified, 200 OK 
to IMS B 




29 


200 OK 


IMS B forwards 200 OK response to IMS A 






30 


200 OK 


IMS_A forwards 200 OK response to IMS_A AS 




31 


200 OK 


IMS_A AS forwards, possibly modified, 200 OK 
response to IMS A 




32 
33 


200 OK 


IMS_A forwards the 200 OK response to UE_A 
User A is informed that call has been answered 


«— 























4.5.5.10 Supplementary Services OIP and OIR with AS in roaming 



Interoperability Test Description 


Identifier: 


TD IMS SS 0010 


Summary: 


IMS network supports properly application services based on the example of the OIP 
and OIR supplementary services. 


Configuration: 


CF ROAM AS 


SUT 


IMS A and IMS B 


References 


Test Purpose 


Specification Reference 


TP IMS 5046 01 


TS 124 229 [1], clause 5.2.6.3 115 


TP IMS 5097 09 


TS 124 229 [1], clause 5.4.3.2 fl 


TP IMS 5308 01 


TS 124 229 [1], clause 5.4.4.2.2 112 


TP IMS 5308 02 


TS 124 229 [1], clause 5.4.4.2.2 112 


TP IMS 5067 01 


TS 124 229 [1], clause 5.2.7.2 117 


Use Case ref.: 


UC 09 R J 


Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UE_A and UE_B have IP bearers established to their respective IMS networks 
as per clause 4.2.1 

• UE_A is registered in IMS_A using userOIP_priv identity according to table 1 

• UE B is registered in IMS B via IMS A using userOIR priv identity according 
to table 1 

• IMS_A is configured to contact AS_A (OIP) 

• UEA is subscribed to OIP service 

• IMS_B is configured to contact AS_B (OIR) 

• UE B is subscribed to OIR service 
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Interoperability Test Description 


Test Sequence: 


Step 




1 


User B calls User A (i.e. userOIP in IMS A) 


2 


Verify that user A is informed of incoming call of User B and User B's 
identity is not displayed 


3 


Verify that user B is informed that UE A is ringing 


4 


User A answers call 


5 


Verify that user B is informed that call has been answered 


6 


Verify that user A is informed that the call is established 


7 


User A ends call 


8 


Verify that user B is informed that call has ended 


9 


Verify that user A is informed that call has ended 


1 1 


Conformance 
Criteria: 


Check 




1 


TP_IMS_5046_01 in CFW step 4 (INVITE) 
ensure that { 
when { IMS A receives an initial INVITE from UE B} 
then { IMS_A sends the INVITE to IMS_B 
containing a Route header 

not indicating the P-CSCF_SIP_URI of IMS_A and 
containing a Route_header 
indicating the "list of Service Route header URIs 
from the registration" and 
containing an additional Via_header 
containing ( the P-CSCF via port number and 
(the P-CSCF-FQDN address or 
the P-CSCF-IP_address)) of IMS_A and 
containing an additional topmost Record-Route_header 
indicating (the P-CSCF_port_number 

'where it awaits subsequent requests' from UE A and 
(the P-CSCF-FQDN address or 
the P-CSCF-IP_address)) of IMS_A and 
not containing P-Preferred-ldentity_header and 
containing a P-Asserted-ldentity_header 

containing an address of UEB and 
containing a P-Charging-Vector_header 
containing an icid parameter} 
} 




2 


TP_IMS_5097_09 in CFW step 6 (INVITE) 
ensure that { 
when { IMS B receives an initial INVITE from IMS_A addressed to UE Bj 
then { IMS_B sends the initial INVITE to AS_B 
containing a Route_header 

indicating the SIP_URI of AS_B and 
containing a P-Charging-Function-Addresses_header and 
containing a P-Charging-Vector_header 
including a orig-ioijparameter 

indicating operatorjdentifier of IMS_A and 
not including a term-ioi parameter} 
} 


3 


TP_IMS_5308_01 in CFW step 20 (180 ringing) 
ensure that { 
when { IMS_A receives a 180 response from UEA 
containing a P-Charging-Vector_header 
including an access-network-charging-info_parameter 

} 

then { IMS_A sends the 180 response to AS_A 
containing a P-Charging-Vector_header 
including an access-network-charging-info parameter 
} 


3 


TP_IMS_5308_02 in CFW step 30 (200 OK) 
ensure that { 
when { IMS_A receives a 200 response from UEA 
containing a P-Charging-Vector_header 
including an access-network-charging-info_parameter 

} 

then { IMS_A sends the 200 response to AS_A 
containing a P-Charging-Vector header 
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Interoperability Test Description 






including an access-networl<-cliarging-info parameter 
} 


4 


TP_IMS_5067_01 in CFW step 4 (INVITE) 
ensure ttiat { 
wlien { /MS A receives an initial INVITE from UE Bj 
then { IMS_A sends the INVITE to IMS_B 

containing a P-Charging-Vector header 
} 
} 



Step 


Direction 


Message 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


A 
S 
A 


1 

M 
S 
B 


A 
S 
B 






1 








» 














User B calls User A 


2 




















INVITE 


UE_B sends INVITE with the first SDP offer 
indicating all desired media and codecs that 
UE B supports 




3 


100 Trying 


ll\/IS_A responds with a 100 Trying provisional 
response 




4 


INVITE 


IMS A forwards INVITE to IMS B 


f 




5 


100 Trying 


ll\/IS_B responds with a 100 Trying provisional 
response 




























INVITE triggers the OIR IPC in IMS B 


6 












f 








INVITE 


IMS B forwards the INVITE to IMS B AS 




7 


100 Trying 


IMS_B AS optionally responds with a 100 Trying 
provisional response 




8 


INVITE 


IMS_B AS returns modified INVITE including 
Privacy header (value "id" or "header") to IIVIS B 




9 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 




10 


INVITE 


IMS B forwards the INVITE to IMS A 






11 




















100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




























INVITE triggers the OIP IPC in IMS A 


12 






' 














INVITE 


IMS A forwards the INVITE to IMS A AS 


^ 


13 


100 Trying 


IMS A AS optionally responds with a 1 00 Trying 
provisional response 


^ 


14 


INVITE 


IMS_A AS returns modified INVITE including 
modified Prom and P-Asserted headers to 
IMS A 


N. 


15 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 




16 


INVITE 


IMS A forwards the INVITE to UE A 










17 


100 Trying 


UE_A optionally responds with a 100 Trying 
provisional response 










18 




^ 


















User A is informed of incoming call of User B, 
user B's identity is not displayed 




19 












>. 








180 Ringing 


UE_A responds to initial INVITE with 180 
Ringing to indicate that it has started alerting 








20 


180 Ringing 


IMS A forwards the 180 Ringing to IMS A 
AS 




21 


180 Ringing 


IMS_A AS forwards, possibly modified, 180 
Ringing to IMS A 




22 


180 Ringing 


IMS A forwards 180 Ringing response to 
IMS B 






23 


180 Ringing 


IMS B forwards 180 Ringing response to 
IMS_B AS 




24 


180 Ringing 


IMS_B AS forwards, possibly modified, 180 
Ringing response to IMS_B 
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Step 


Direction 


IVIessage 


Comment 
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s 
e 
r 
A 
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U 
s 
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r 
B 


U 

E 
B 


1 

M 
S 
A 


A 
S 
A 


1 

M 
S 
B 


A 
S 
B 






25 










^ 










180 Ringing 


ll\/IS B forwards the 1 80 Ringing response to 
IMS A 






26 


180 Ringing 


ll\/IS A forwards the 1 80 Ringing response to 
UE B 




27 
28 




> 




i 














User B is informed that UE A is ringing 
User A answers call 


29 










N 










200 OK 


UE_A responds INVITE with 200 OK to indicate 
that the call has been answered 






^ 


30 


200 OK 


IMS A forwards the 200 OK to IMS A AS 


f 


31 


200 OK 


IMS A AS forwards, possibly modified, 200 OK 
to IMS A 




32 


200 OK 


IMS A forwards 200 OK response to IMS B 






33 


200 OK 


IMS_B forwards 200 OK response to IMS_B AS 




34 


200 OK 


IMS_B AS forwards, possibly modified, 200 OK 
response to IMS_B 




35 


200 OK 


IMS B forwards the 200 OK response to IMS A 






36 
37 


200 OK 


IMS_A forwards the 200 OK response to UE_B 
User B is informed that call has been answered 





























4.5.5.11 



Ad-hoc Conference Call service 



Interoperability Test Description | 


Identifier: 


ID IMS CONF 0001 


Summary: 


IMS network handles subsequent INVITEs, UPDATES, REFERs and NOTIFYs 
correctly during Ad-Hoc Conference calls. 


^^^ -^^^m 


Configuration: 


OF INT CONF ALL 


SUT 


IMS A 


References 


Test Purpose 


Specification Reference 


TP IMS 5121 02 


TS 124 229 fll, clause 5.4.3.3 1153 


Use Case ref.: 


UC_16 1 




Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UEA and UEB have IP bearers established to their respective IMS networks 
as per clause 4.2.1 

• UE_A is registered in IMS_A using any user identity 

• IMS_A is configured to contact AS_A (CONF) 

• UE_B is registered in IMS_B using any user identity 

• IMS_B is configured to contact AS_B (CONF) 

• User A and B are subscribed to CONF service 

• User A is pre-provisioned with conference-factory URI in IMS A 




Test Sequence: 


Step 




1 


User A initiates an ad-hoc conference call with a pre-configured conference- 
factory URI 


2 


Verify that User A is informed the Ad Hoc Conference Call is being set up 


3 


Verify that User A is informed the Ad Hoc Conference Call is established 


4 


User A invites User B to join the Conference Call. 


5 


Verify that User B is informed of incoming invitation from User A to join the 
Conference Call 


6 


Verify that User A is informed that User B is being alerted 


7 


User B joins the Conference Call 


8 


Verify that User A is alerted when User B joins the Conference Call 


9 


User B leaves the Conference Call 


10 


Verify that User B is informed that the Conference Call has ended 


11 


Verify that User A is alerted when User B leaves the Conference Call 
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Interoperability Test Description 



Conformance 
Criteria: 



Check 



TP_IMS_5121_02 in CFW in step 36 & 37 (200 OK ); 
ensure that { 

when { UEB sends a 1xx or 2xx_response to UEA } 
then { IMS_A receives the 1xx or 2xx_response 
containing a P-Charging-Vector_header 

not containing a access-networl<-charging-info_parameter and 
not containing a P-Access-Networl<-lnfo_header } 
1 



Step 


Direction 


Message 


Comment 




U 
s 
e 
r 
A 


u 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


A 
S 
A 


1 

M 
S 
B 


A 
S 
B 






1 




> 


















User A initiates an ad-hoc conference call 


2 




















INVITE 


UE_A sends INVITE to IMS_A with 
information for all commonly supported 
presence elements 








3 


100 Trying 


IMS_A responds with a 100 Trying 
provisional response 








4 




y 


















User A is informed the Ad Hoc 
Conference Gall is being set up 




5 












V 








INVITE 


IMS A forwards INVITE to IMS A AS 




6 


100 Trying 


IMS_A AS responds with a 100 Trying 
provisional response 




7 


200 OK 


IMS_A AS responds with a 200 OK to 
IMS A, with isfocus parameter. 




8 


200 OK 


IMS A forwards the 200OK response to 
UE A 








9 




^ 


















User A is informed the Ad Hoc 
Conference Call is established 




10 










V 










ACK 


UE A acknowledges the receipt of 200 
OK for INVITE 








11 


ACK 


IMS A forwards the ACK to IMS A AS 




12 




>. 


















User A invites user B to join the ad-hoc 
conference call 




13 










>. 




■N. 






REFER 


UEA sends REFER message to IMS_A, 
with Refer-To : <UE B uri 
;method=INVITE> 








14 


REFER 


IMS A forwards the REFER to IMS A AS 




15 


202 
Accepted 


IMS_A AS responds with a 202 Accepted 




16 


202 
Accepted 


IMS_A forwards the 202 Accepted 
response to UE A 








17 


NOTIFY 


IMS_A AS sends a NOTIFY to IMS_A to 
inform the conference initiator the 
REFER message is being processed 




18 


NOTIFY 


IMS A forwards the NOTIFY to UE A 






V 


19 


200 OK 


UE A responds with 200 OK to IMS A 








20 


200 OK 


IMS A forwards the 200 OK response to 
IMS A AS 




21 


INVITE 


IMS_A AS sends INVITE to UE_B with 
conference-factory URI (received in the 
REFER message from UE A) 




22 


100 Trying 


IMS_A responds with a 100 Trying 
provisional response 




23 


INVITE 


IMS A forwards the INVITE to IMS B 


^ 




24 


100 Trying 


IMS_B responds with a 100 Trying 
provisional response 






25 


INVITE 


IMS B forwards the INVITE to UE B 
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Step 


Direction 


IVIessage 


Comment 




U 
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r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


u 

E 
B 


1 

M 
S 
A 


A 
S 
A 


1 

IVI 
S 
B 


A 
S 
B 






26 




















100 Trying 


UE_B responds with a 100 Trying 
provisional response 








27 






















User B is informed of incoming invitation 
from User A to join the Conference Call 


i 




28 














V 






180 Ringing 


UE B sends a 180 ringing to IMS B 








29 


180 Ringing 


IMS B forwards the 180 ringing to IMS A 






30 


180 Ringing 


IMS A forwards the 180 ringing to IMS A 
AS 




31 


NOTIFY 


Upon reception of 180 Ringing from 
UE_B, IMS_A AS sends NOTIFY with 
sipfrag: 180 Ringing to inform 
conference initiator that UE_B is being 
invited to join the conference 




32 


NOTIFY 


IMS A forwards the NOTIFY to UE A 








33 






















User A is notified that User B is being 
invited to join the call 




34 










V 




>. 






200 OK 


UE A responds with 200 OK to IMS A 
for NOTIFY 








35 


200 OK 


IMS A forwards the 200 OK response to 
IMS A AS 




36 


200 OK 


UE B responds witli 200 OK to IMS B 
for INVITE 








37 


200 OK 


IMS B forwards the 200 OK response 
to IMS A 






38 


200 OK 


IMS A forwards the 200 OK response to 
IMS A AS 




39 








> 














User B joins the conference 


40 






^ 








>. 






ACK 


UE B acknowledges the 200 OK for 
INVITE 








41 


ACK 


IMS B forwards the ACK to IMS A 






42 


ACK 


IMS A forwards the ACK to IMS A AS 




43 


NOTIFY 


AS_A sends NOTIFY to UE_A to inform it 
has successfully joined the conference 




44 


NOTIFY 


IMS A forwards NOTIFY to UE A 








45 






















User A is alerted that User B has joined 
the conference 


^ 




46 




















200 OK 


UE A sends 200 OK response for 
NOTIFY 








47 


200 OK 


IMS A forwards the 200 OK response to 
IMS A AS 




48 








> 














User B leaves the conference 


49 




















BYE 


UE_B sends BYE to IMS_B to leave the 
conference 




^ 




50 


BYE 


IMS B forwards the BYE to IMS A 


»- 




51 


BYE 


IMS A forwards the BYE to IMS A AS 




52 


200 OK 


IMS_A AS releases resources for this 
conference caller and sends a 200 OK 
response for BYE 




53 


200 OK 


IMS A forwards the 200 OK response to 
IMS B 






54 


200 OK 


IMS B forwards the 200 OK response to 
UE B 








55 








^ 














User B is informed that the conference 
has ended 




56 












^ 








NOTIFY 


AS_A sends NOTIFY to IMS _A to inform 
UE A that UE B has left the conference 




57 


NOTIFY 


IMS A forwards NOTIFY to UE A 








58 




^ 


















User A is notified that user B has left the 
conference 




59 










»» 










200 OK 


UE A sends a 200 OK response for 
NOTIFY 
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1 
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A 


1 
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s 
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A 
S 
B 






60 




















200 OK 


IMS A forwards the 200 OK response to 
IMS A AS 





























4.5.6 Presence 



4.5.6.1 



Watcher subscription for presence event notification in visited network 



Interoperability Test Description 


Identifier: 


ID IMS PRES 0001 


Summary: 


IMS network supports properly presence service when a watcher subscribes to 
presence information for a presentity that it's located in a different network. 


Configuration: 


OF ROAM AS 


SUT 


IMS B 


References 


Test Purpose 


Specification Reference 


IP IMS 5097 13 


TS 124 229 [1], clause 5.4.3.2 HI 


IP IMS 5108 06 


TS 124 229 [1], clause 5.4.3.3 HI 


IP IMS 5115 08 


TS 124 229 [1], clause 5.4.3.3 1165 


Use Case ref.: 

1 ^^^^^m 


UC 17 R 1 


1 ^^^^^M 

Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UE_A and UE_B have IP bearers established to their respective IMS networks as 
per clause 4.2.1 

• UEA is registered in IMS_A using userPRES according to table 1 

• UEB is registered in IMS_B via IMS A using userPRES according to table 1 

• UE_A is configured to receive notifications with watcher information 

• IMS_A is configured to contact AS_A 

• IMS_B is configured to contact AS_B 

• AS_Bis configured for reactive autorization 

• IMS_A is within the trust domain of IMS_B 

• IMS_A not configured for topology hiding 


^^^^^^^^^^^ 




Test Sequence: 
I 


Step 


^M 


1 


User B publishes presence information 


2 


User B is informed of its presence status update 


3 


User A subscribes to presence information from User B 


4 


User B receives an authorization request from User A to see its own 
presence information 


5 


User B authorizes user A to be informed of its own presence information 


6 


User A is informed of User B presence information 


I 

Conformance 
Criteria: 


Check 




1 


TP_IMS_5097_13 in CFW step 4 (PUBLISH); 
ensure that { 
when {IMS B receives a PUBLISH from IMS A } 
then { IMS_B sends the PUBLISH to AS_B 
containing a Route_header 

indicating the SIP_URI of AS_B and 
containing a P-Charging-Function-Addresses_header and 
containing a P-Charging-Vector_header 

containing an orig-ioi parameter indicating IMS_A and 
not containg a term-ioi parameter} 
} 


2 


TP_IMS_5108_06 in CFW step 1 1 & 12 (SUBSCRIBE): 
ensure that { 

when { IMS A receives a SUBSCRIBE addressed to UE B} 
then { IMS_B sends the SUBSCRIBE to AS_B 
containing a topmost Route header 
indicating the SIP URI of AS B 
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Interoperability Test Description 






containing a Route tieader 

indicating tlie S-CSCF_SIP URI of IMS_B 
containing a P-Cliarging-Vector_lieader 

containing an orig-ioi parameter indicating IMS_A and 
not containg a term-ioi parameter} 
} 
} 




3 


TP_IMS_51 1 5_08 in CFW step 1 3 & 1 4 (200 OK): 
ensure ttiat { 

wlien { AS_B sends a 200 response to UEA } 
tlien { iMS_B receives the 200 response 

containing a P-Cliarging-Vector_lieader 
containing a orig-ioi_parameter indicating IMS_A and 
containing a term-ioi parameter indicating IMS B } 

} 



Step 


Direction 


Message 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


A 
S 
A 


1 

M 
S 
B 


A 
S 
B 






1 






















User B publishes presence information 


> 


2 














*. 






PUBLISH 


UE_B sends PUBLISH witli information 
for all commonly supported presence 
elements 


^ 


3 


PUBLISH 


IMS A forwards the PUBLISH to IMS B 






4 


PUBLISH 


IMS B forwards the PUBLISH to 
IMS BAS(PS) 




5 


200 OK 


IMS B AS responds with a 200 OK to 
IMS B 




6 


200 OK 


IMS B forwards the 200 OK response to 
IMS A 






7 


200 OK 


IMS A forwards the 200 OK response to 
UE B 




8 








^ 














User B is informed of its presence status 
update 




9 




User A subscribes to presence 
information from User B 


> 




10 










>. 










SUBSCRIBE 


UE_A sends SUBSCRIBE for "presence" 
event to IMS A 


^ 






11 


SUBSCRIBE 


IMS A forwards the SUBSCRIBE to 
IMS B 


^ 




12 


SUBSCRIBE 


IMS B forwards the SUBSCRIBE to 
IMS_B AS (PS) 




13 


200 OK 


IMS B AS responds with a 200 OK to 
IMS B 




14 


200 OK 


IMS B forwards the 200 OK response 
to IMS A 






15 


200 OK 


IMS A forwards the 200 OK response to 
UE A 


^ 






16 


NOTIFY 


IMS B AS sends NOTIFY to IMS A 






V 


17 


NOTIFY 


IMS A forwards the NOTIFY to UE A 








18 


200 OK 


UE A responds with a 200 OK to IMS A 








19 


200 OK 


IMS A forwards the 200 OK response to 
IMS BAS 






























SUBSCRIPTION triggers the AS to send 
a NOTIFY to UEB indicating the change 
to the watcher information subscriber 


20 












^ 








NOTIFY 


IMS_B AS sends NOTIFY to IMS_B to 
indicate UE_B the change to the watcher 
information subscriber 




21 


NOTIFY 


IMS B forwards the NOTIFY to IMS A 






22 


NOTIFY 


IMS A forwards the NOTIFY to UE B 


x 


23 


200 OK 


UE B responds with a 200 OK to IMS A 




y 
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24 




















200 OK 


IMS A forwards the 200 OK response to 
IMS B 






25 


200 OK 


IMS B forwards the 200 OK response to 
IMS BAS 




26 








^ 














User B receives an authorization request 
from User A to see its own presence 
information 

























4.5.6.2 



Watcher subscription to presence event notification in home network 



Interoperability Test Description 


Identifier: 


ID IMS PRES 0002 


Summary: 


IMS networl< supports properly presence service when a watcher subscribes to 




presence information for a presentity that it's located in a different networl<. 


Configuration: 


OF INT AS 


SUT 


IMS A 


References 


Test Purpose 


Specification Reference 


IP IMS 5108 06 


TS 124 229 [1], clause 5.4.3.3 111 


IP IMS 5115 08 


TS 124 229 [1], clause 5.4.3.3 1165 


Use Case ref.i 


UC 17 1 1 


^^^^^^■^^_ 


r- \ 


Pre-test 


• HSS of IMS_A and of IMS B is configured according to table 1 


conditions: 


• UE A and UE B have IP bearers established to their respective IMS networks as 




per clause 4.2.1 




• UEA is registered in IMS_A using userPRES according to table 1 




• UE_B is registered in IMS_B using userPRES according to table 1 




• UE_B is configured to receive notifications with watcher information 




• AS_B is configured for reactive authorization 




• IMS_A is configured to contact AS_A (PS) 




• IMS A is within the trust domain of IMS B 




• IMS A not configured for topology hiding 




Test Sequence: 


Step 


99 


1 


User B publishes presence information 


2 


User B is informed of its presence status update 


3 


User A subscribes to presence information from User B 


4 


User B receives an authorization request from User A to see its own 


1 




presence information 


5 


User B authorizes user A to be informed of its own presence information 


6 


User A is informed of User B presence information 


Conformance 


Cliecl< 




Criteria: 







1 


TP_IMS_5108_06 in CFW step 9 & 10 (SUBSCRIBE): 






ensure that { 






when { IMS A receives a SUBSCRIBE addressed to UE B} 






then {IMS B sends the SUBSCRIBE to AS B 






containing a topmost Route header 






indicating the SIP URI of AS_B 






containing a Route header 






indicating the S-CSCF_SIP URI of IMS_B 






containing a P-Charging-Vector_header 






containing an orig-ioi parameter indicating IMS_A and 






not containg a term-ioi parameter} 

} 
I 
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Interoperability Test Description 



TP_IMS_5115_08 in CFW step 11 & 12 (200 OK); 
ensure that { 

when { AS_B sends a 200 response to UEA } 
then { IMS_B receives the 200 response 

containing a P-Charging-Vector_header 
containing a orig-ioi_parameter indicating IMS_A and 
containing a term-ioi_parameter indicating IMS_B } 
} 



Step 


Direction 


Message 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


u 

E 
B 


1 

M 
S 
A 


A 
S 
A 


1 

M 
S 
B 


A 
S 
B 






1 






















User B publishes presence information 


> 


2 














N. 






PUBLISH 


UE_B sends PUBLISH witli information 
for all commonly supported presence 
elements 


^ 






3 


PUBLISH 


IMS B forwards the PUBLISH to IMS B 
AS (PS) 


f 


4 


200 OK 


IMS B AS responds with a 200 OK to 
IMS B 




5 


200 OK 


IMS B forwards the 200 OK response to 
UE B 








6 






















User B is informed of its presence status 
update 


i 




7 




User A subscribes to presence 
information from User B 


> 




8 




















SUBSCRIBE 


UE_A sends SUBSCRIBE for "presence" 
event to IMS A 








9 


SUBSCRIBE 


IMS A forwards the SUBSCRIBE to 
IMS B 


f 




10 


SUBSCRIBE 


IMS B forwards the SUBSCRIBE to 
IMS BAS(PS) 


f 


11 


200 OK 


IMS B AS responds with a 200 OK to 
IMS B 




12 


200 OK 


IMS B forwards the 200 OK response 
to IMS A 






13 


200 OK 


IMS A forwards the 200 OK response to 
UE A 








14 


NOTIFY 


IMS B AS sends NOTIFY to IMS A 








15 


NOTIFY 


IMS A forwards the NOTIFY to UE A 






■N. 


16 


200 OK 


UE A responds with a 200 OK to IMS A 








17 


200 OK 


IMS A forwards the 200 OK response to 
IMS BAS 






























SUBSCRIPTION triggers the AS to send 
a NOTIFY to UEB indicating the change 
to the watcher information subscriber 


18 










^ 






f 




NOTIFY 


IMS_B AS sends NOTIFY to IMS_B to 
indicate UE_B the change to the watcher 
information subscriber 


V 


19 


NOTIFY 


IMS B forwards the NOTIFY to UE B 








20 


200 OK 


UE B responds with a 200 OK to IMS B 








21 


200 OK 


IMS B forwards the 200 OK response to 
IMS BAS 




22 








^ 














User B receives an authorization request 
from User A to be informed of its own 
presence information 
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4.5.6.3 Unsuccessful watcher subscription to presence event notification in liome 

network 



Interoperability Test Description | 


Identifier: 


ID IMS PRES 0003 


Summary: 


IMS network supports properly presence service when a watcher subscribes to 
presence information for a presentity that it's located in a different network and does 
not authorize the watcher to be informed of his presence information. 


Configuration: 


CF INT AS 


BUT 


IMS B 


References 


Test Purpose 


Specification Reference 


IP IMS 5108 06 


TS 124 229 [1], clause 5.4.3.3 HI 


Use Case ref.: 


UC 17 1 1 


Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UE_A and UE_B have IP bearers established to their respective IMS networks as 
per clause 4.2.1 

• UEA is registered in IMS_A using userPRES according to table 1 

• UEB is registered in IMS_B using userPRES according to table 1 

• UE_A is not authorized to see the presence of UE_B 

• IMS_B is configured to contact AS_B (PS) 

• IMS_A is within the trust domain of IMS_B 

• IMS A not configured for topology hiding 


Test Sequence: 
1 


Step 




1 


User A subscribes to presence information from User B 


2 


User A is not informed of User B presence information 


1 

Conformance 
Criteria: 


Checl< 




1 


TP_IMS_5108_06 in CFW step 3 & 4 (SUBSCRIBE): 
ensure that { 

when { IMS A receives a SUBSCRIBE addressed to UE B} 
then { IMS_B sends the SUBSCRIBE to AS_B 
containing a topmost Route header 

indicating the SIP URI of AS_B 
containing a Route header 

indicating the S-CSCF_SIP URI of IMS_B 
containing a P-Charging-Vector_header 

containing an orig-ioi parameter indicating IMS_A and 
not containg a term-ioi parameter} 
} 
} 



Step 


Direction 


Message 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


A 
S 
A 


1 

IVI 
S 
B 


A 
S 
B 






1 




V 


















User A subscribes to presence 
information from User B 




2 














V 






SUBSCRIBE 


UE_A sends SUBSCRIBE for 
"presence" event to IMS A 








3 


SUBSCRIBE 


IMS A forwards the SUBSCRIBE to 
IMS B 






4 


SUBSCRIBE 


IMS B forwards tlie SUBSCRIBE to 
IMS_B AS (PS) 




5 


2xx or 4xx 
response 


IMS B AS responds with a 200 OK to 
IMS B 




6 


2xx or 4xx 
response 


IMS B AS responds with a 200 OK to 
IMS A 






7 


2xx or 4xx 
response 


IMS A forwards the 200 OK response 
toUE A 
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Step 


Direction 


Message 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


A 
S 
A 


1 
IVI 

s 

B 


A 
S 
B 




























User A is not informed of User B 
presence information 





























4.5.6.4 



Watcher subscription to resource list in visited network. 



Interoperability Test Description 


Identifier: 


ID IMS PRES 0004 


Summary: 


IIVIS networl< supports properly presence service when a watcher subscribes to a 
resource list containing one or more presentities located in different networks. 


Configuration: 


OF ROAM AS 


SUT 


IMS B 


References 


Test Purpose 


Specification Reference 


IP IMS 5097 13 


TS 124 229 [1], clause 5.4.3.2 HI 


IP IMS 5108 06 


TS 124 229 [1], clause 5.4.3.3 HI 


IP IMS 5313 01 


TS 1 24 229 [1 1, clause 5.4.6.1.3 112 


Use Case ref.: 


UC 18 R J 


Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UE_A and UE_B have IP bearers established to their respective IMS networks as 
per clause 4.2.1 

• UEA is registered in IMS_A using userPRES according to table 1 

• UEB is registered in IMS_B via IMS A using userPRES according to table 1 

• UE_A is authorized to see UE_B presence information 

• UE_A is authorized to use the resource list userPRESJist: 

• IMS_A is within the trust domain of IMS_B 

• IMS_B is configured to contact AS_B (PS) 

• IMS A, IMS B not configured for topology hiding 




Test Sequence: 


Step 




1 


User B publishes presence information 


2 


User B is informed of its presence status update 


3 


User A subscribes to resource list userPRES list containing UserB SIP URI 


4 


User A sees User B presence information 


^^^ 


Conformance 
Criteria: 


Checl< 


1 


1 


TP_IMS_5097_13 in CFW step 4 (PUBLISH): 
ensure that { 
when {IMS B receives a PUBLISH from IMS A } 
then { IMS_B sends the PUBLISH to AS_B 
containing a Route_header 

indicating the SIP_URI of AS_B and 
containing a P-Charging-Function-Addresses_header and 
containing a P-Charging-Vector_header 

containing an orig-ioi parameter indicating IMS_A and 
not containg a term-ioi parameter} 

} 


2 


TP_IMS_5108_06 in CFW step 19 & 20 (SUBSCRIBE): 
ensure that { 

when { IMS A receives a SUBSCRIBE addressed to UE Bj 
then { IMS_B sends the SUBSCRIBE to AS_B 
containing a topmost Route header 

indicating the SIP URI of AS_B 
containing a Route header 

indicating the S-CSCF_SIP URI of IMS_B 
containing a P-Charging-Vector_header 

containing an orig-ioi parameter indicating IMS_A and 
not containg a term-ioi parameter} 
} 
} 
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Interoperability Test Description 



TP_IMS_5313_01 in CFW step 22 & 23 (200 OK) 
ensure that { 
when { IMS_A receives a response from IMS_B 
containing a P-Charging-Vector_header 
including an access-networl<-charging-info__parameter 

} 

then { IMS_A sends the response to AS_A 

containing a P-Charging-Vector_header 
including an access-networl<-charging-info_parameter 
} 
I 



Step 


Direction 


Message 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


A 
S 
A 


1 

M 
S 
B 


A 
S 
B 






1 






















User B publishes presence information 






2 
















■N. 




PUBLISH 


UE_B sends PUBLISH witli information 
for all commonly supported presence 
elements 




3 


PUBLISH 


IMS A forwards the PUBLISH to IMS B 






4 


PUBLISH 


IMS B forwards the PUBLISH to 
IMS_B AS (PS) 


^ 


5 


200 OK 


IMS B AS responds with a 200 OK to 
IMS B 




6 


200 OK 


IMS B forwards the 200 OK response to 
IMS A 






7 


200 OK 


IMS A forwards the 200 OK response to 
UE B 




8 








^ 














User B is informed of its presence status 
update 




9 




User A subscribes to resource list 


> 


10 












V 








SUBSCRIBE 


UE_A sends SUBSCRIBE for "presence" 
event to IMS_A indicating support to 
"eventlist" to a resource list SIP URI 








11 


SUBSCRIBE 


IMS A forwards the SUBSCRIBE to 
IMS AAS(RLS) 


























RLS performs authorization checks to 
ensure that User A is authorized to use 
resource lists 


12 






f 






^ 








200 OK 


IMS A AS responds with a 200 OK to 
IMS A 




13 


200 OK 


IMS A forwards the 200 OK response to 
UE A 


f 






14 


NOTIFY 


IMS A AS sends NOTIFY to IMS A 


V 


15 


NOTIFY 


IMS A forwards the NOTIFY to UE A 








16 


200 OK 


UE A responds with a 200 OK to IMS A 








17 


200 OK 


IMS A forwards the 200 OK response to 
IMS A AS 


























RLS resolves watcher resource's 
address and subscribes for presence 
event notification for all the presentities 
represented by the resource list SIP URI 


18 
















■N. 




SUBSCRIBE 


IMS_A AS (RLS) sends SUBSCRIBE for 
"presence" event to IMS A 




19 


SUBSCRIBE 


IMS A forwards the SUBSCRIBE to 
IMS B 






20 


SUBSCRIBE 


IMS B forwards the SUBSCRIBE to 
IMS_B AS (PS) 


























PS performs authorization checks on the 
originator to ensure it is allowed to watch 
the presentity 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

lUI 
S 
A 


A 
S 
A 


1 

M 
S 
B 


A 
S 
B 






21 




















200 OK 


IMS B AS (PS) responds with a 200 OK 
to IMS B 




22 


200 OK 


IIVIS B forwards the 200 OK response 
tollVIS A 


■N. 




23 


200 OK 


IIVIS A forwards the 200 OK response 
to IMS AAS(RLS) 


^ 


24 


NOTIFY 


IMS_B AS sends a NOTIFY to IMS_A 
with the presence information of UE B 


>. 






25 


NOTIFY 


IMS A forwards the NOTIFY to IMS A 
AS (RLS) 




26 


200 OK 


IMS A AS responds with a 200 OK to 
IMS A 




27 


200 OK 


IMS A forwards the 200 OK response to 
IMS BAS 






























RLS notifies with presence information 
for all the presentities represented by the 
resource list SIP URI 


28 






^ 














NOTIFY 


IMS A AS sends NOTIFY to IMS A 


>. 


29 


NOTIFY 


IMS A forwards the NOTIFY to UE A 








30 


200 OK 


UE A responds with a 200 OK to IMS A 








31 


200 OK 


IMS A forwards the 200 OK response to 
IMS A AS 




32 




i 


















User A sees user B presence information 



4.5.6.5 



Watcher subscription to resource list in home network 



Interoperability Test Description | 


Identifier: 


TD IMS PRES 0005 


Summary: 


IMS network supports properly presence service when a watcher subscribes to a 
resource list containing one or more presentities located in different networks. 


Configuration: 


CF INT AS 


SUT 


IMS A 


References 


Test Purpose 


Specification Reference 


TP IMS 5108 06 


TS 124 229 [1], clause 5.4.3.3 111 


TP IMS 5313 01 


TS 1 24 229 [1 1, clause 5.4.6.1.3 112 


Use Case ref.: 

1 ^^^^H 


UC 18 1 1 


1 ^^^^^H 

Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UEA and UEB have IP bearers established to their respective IMS networks as 
per clause 4.2.1 

• UEA is registered in IMS_A using userPRES according to table 1 

• UEB is registered in IMS_B using userPRES according to table 1 

• UE_A is authorized to see UE_B presence information 

• UE_A is authorized to use the resource list userPRESJist: 

• IMS_A is within the trust domain of IMS_B 

• IMS_A is configured to contact AS_A (RLS) 

• IMS_B is configured to contact AS_B (PS) 

• IMS_A, IMS_B not configured for topology hiding 


1 1 


Test Sequence: 


Step 




1 


User B publishes presence information 


2 


User B is informed of its presence status update 


3 


User A subscribes to resource list containing User B SIP URI 


4 


User A sees User B presence information 
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Interoperability Test Description 



Conformance 
Criteria: 



Check 



TP_IMS_5108_06 in CFW step 17 & 18 (SUBSCRIBE): 
ensure that { 

when { IMS_A receives a SUBSCRIBE addressed to UE_B} 
then { IMS_B sends the SUBSCRIBE to AS_B 
containing a topmost Route header 

indicating the SIP URI of AS_B 
containing a Route header 

indicating the S-CSCF_SIP URI of IMS_B 
containing a P-Charging-Vector_header 

containing an orig-ioi parameter indicating IMS_A and 
not containg a term-ioi parameter} 
} 
1 



TP_IMS_5313_01 in CFW step 20 & 21 (200 OK) 
ensure that { 
when { IMS_A receives a response from IMS_B 
containing a P-Charging-Vector_header 
including an access-network-charging-info_parameter 

} 

then { IMS_A sends the response to AS_A 

containing a P-Charging-Vector_header 
including an access-network-charging-info_parameter 
} 
I 



Step 


Direction 


Message 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


A 
S 
A 


1 

M 
S 
B 


A 
S 
B 






1 








> 














User B publishes presence information 


2 




















PUBLISH 


UE_B sends PUBLISH with information 
for all commonly supported presence 
elements 


^ 






3 


PUBLISH 


IMS B forwards the PUBLISH to IMS B 
AS (PS) 




4 


200 OK 


IMS B AS responds with a 200 OK to 
IMS B 




5 


200 OK 


IMS B forwards the 200 OK response to 
UE B 








6 

7 




> 




^ 














User B is informed of its presence status 

update 

User A subscribes to resource list 




8 




















SUBSCRIBE 


UE_A sends SUBSCRIBE for "presence" 
event to IMS_A indicating support to 
"eventlist" to a resource list SIP URI 








9 


SUBSCRIBE 


IMS A forwards the SUBSCRIBE to 
IMS AAS(RLS) 


























RLS performs authorization checks to 
ensure that User A is authorized to use 
resource lists 


10 




















200 OK 


IMS A AS responds with a 200 OK to 
IMS A 


^ 


11 


200 OK 


IMS A forwards the 200 OK response to 
UE A 








12 


NOTIFY 


IMS A AS sends NOTIFY to IMS A 




13 


NOTIFY 


IMS A forwards the NOTIFY to UE A 






>. 


14 


200 OK 


UE A responds with a 200 OK to IMS A 








15 


200 OK 


IMS A forwards the 200 OK response to 
IMS A AS 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 
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s 
e 
r 
B 


U 

E 
B 


1 
IVI 

s 

A 


A 
S 
A 


1 

M 
S 
B 


A 
S 
B 




























RLS resolves watcher resource's 
address and subscribes for presence 
event notification for all the presentities 
represented by the resource list SIP URI 


16 












^ 


>. 


V 




SUBSCRIBE 


IMS_A AS (RLS) sends SUBSCRIBE for 
"presence" event to IMS A 




17 


SUBSCRIBE 


IIVIS A forwards tlie SUBSCRIBE to 
IIVIS B 






18 


SUBSCRIBE 


IIVIS B forwards the SUBSCRIBE to 
IIVIS_B AS (PS) 


























PS performs authorization checks on the 
originator to ensure it is allowed to watch 
the presentity 


19 












f 




^ 




200 OK 


IMS B AS (PS) responds with a 200 OK 
to IMS B 




20 


200 OK 


IIVIS B forwards the 200 OK response 
to IMS A 






21 


200 OK 


IIVIS A forwards the 200 OK response 
to IIVIS_A AS (RLS) 




22 


NOTIFY 


IMS_B AS sends a NOTIFY to IMS_A 
with the presence information of UE B 






N. 


23 


NOTIFY 


IMS A forwards the NOTIFY to IMS A 
AS (RLS) 


^ 


24 


200 OK 


IMS A AS responds with a 200 OK to 
IMS A 




25 


200 OK 


IMS A forwards the 200 OK response to 
IMS BAS 






























RLS notifies with presence information 
for all the presentities represented by the 
resource list SIP URI 


26 












f 








NOTIFY 


IMS A AS sends NOTIFY to IMS A 




27 


NOTIFY 


IMS A forwards the NOTIFY to UE A 








28 


200 OK 


UE A responds with a 200 OK to IMS A 








29 


200 OK 


IMS A forwards the 200 OK response to 
IMS A AS 




30 




« 


















User A sees user B presence information 



4.5.7 



IPTV 



4.5.7.1 



IPTV registration and Service Attachment. Pusli mode 



Interoperability Test Description 


Identifier: 


TD IMS IPTV 0001 


Summary: 


IMS network supports properly IPTV registration and service attachment in Push mode. 


Configuration: 


CF IPTV 


SUT 


IMS A 


References 


Test Purpose 


Specification Reference 


TP IMS 5206 01 


TS 124 229 [1], clause 5.4.1.2.2 117 


TP IMS 5308 02 


TS 124 229 [1], clause 5.4.4.2.2 112 


Use Case ret.: 






Pre-test 
conditions: 


• HSS of IMS_A is configured according to table 1 

• UE A has IP bearers established to its respective IMS networks as per clause 
4.2.1 

• UE_A is registered in IMS_A using userlPTV according to table 1 

• IMS_A is configured to send a third party register to AS_A (SDF) 

• IMS A not configured for topology hiding 
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Interoperability Test Description 



Test Sequence: 



Step 



29 



UE receives service attachment information 



Conformance 
Criteria: 



Check 



1 



TP_II\/1S_5206_01 in CFW step 23 (REGISTER) 
ensure that { 

when { IMS_A receives a protected REGISTER 
containing an Authorization header 
containing a integrity protected parameter indicating yes} 

then { IMS_A sends a third party register to AS_A 
} 
}_ 



TP_IMS_5308_02 In CFW step 28 (200 OK) 
ensure that { 
when { lUT receives a 200_response from UEA 
containing a P-Charging-Vector_header 
including an access-network-charging-info_parameter 

} 

then { lUT sends the 200_response to AS_A 
containing a P-Charging-Vector_header 
including an access-network-charging-info_parameter 
} 
I 



Step 


Direction 


Message 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


A 
S 
A 


1 

M 
S 
B 


A 
S 
B 




























IMS_A matches the iFC of the service 
profile belong to the user and find out the 
AS (SDF) that user has subscribed 


23 






^ 














REGISTER 


IMS_A sends a REGISTER to AS_A 
(third party registration) 


f 


24 


200 OK 


AS A responds with 200 OK 




25 


MESSAGE 


AS_A sends a MESSAGE containg the 
service attachment information 


N. 


26 


MESSAGE 


IMS A forwards the MESSAGE to UE A 








27 


200 OK 


UE A responds with 200 OK 








28 


200 OK 


IMS A forwards the 200 OK response 
to AS A 




29 






















UE receives service attachment 
information 



4.5.7.2 



IPTV registration and Service Attachment. Pull mode 



Interoperability Test Description 


Identifier: 


ID IMS IPTV 0002 


Summary: 


IMS network supports properly IPTV registration and service attachment in Pull mode. 


Configuration: 


OF IPTV 


SUT 


IMS A 


References 


Test Purpose 


Specification Reference 


TP IMS 5097 09 


TS 124 229 [1], clause 5.4.3.2 HI 


TP IMS 5308 02 


TS 124 229 [1], clause 5.4.4.2.2 112 


Use Case ref.: 




r 1 


Pre-test 
conditions: 


• HSS of IMS_A is configured according to table 1 

• UEA has IP bearers established to its respective IMS networks as per 
clause 4.2.1 

• UEA is registered in IMS A using userlPTV according to table 1 

• UEA, IMS_A, AS_A support pull mode service discovery 

• IMS A not configured for topology hiding 
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Interoperability Test Description 



Test Sequence: 



Step 



31 



UE receives service attacliment information 



Conformance 
Criteria: 



Check 



TP_IMS_5097_09 in CFW step 24 (SUBSCRIBE): 
ensure that { 

when { IMS_A sends the SUBSCRIBE to AS_A } 
then {AS_A receives the SUBSCRIBE 
containing a Route_header 

indicating the SIP_URI ofAS_A 
containing a P-Charging-Function-Addresses_header 
containing a P-Charging-Vector_header 
(containing a orig-ioi_parameter indicating IMS_A and 
not containing a term-ioi_parameter)} 
I 



TP_IMS_5308_02 in CFW step 30 (200 OK) 
ensure that { 
when { lUT receives a 200_response from UEA 
containing a P-Charging-Vector_header 
including an access-network-charging-info_parameter 

} 

then { lUT sends the 200_response to AS_A 
containing a P-Charging-Vector_header 
including an access-network-charging-info_parameter 
} 
I 



Step 


Direction 


Message 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


A 
S 
A 


1 

M 
S 
B 


A 
S 
B 




























UE retrieves the PSI/address of AS A 

(SDF) 


23 




















SUBSCRIBE 


UE_A sends a SUBSCRIBE for "ua- 
profile" event to IMS A 








24 


SUBSCRIBE 


IMS A forwards the SUBSCRIBE to 
AS A 


^ 


25 


200 OK 


AS A responds with 200OK 




26 


200 OK 


IMS A forwards the 200 OK response to 
UE A 


^ 






27 


NOTIFY 


AS_A sends a NOTIFY for the service 
attachment information to IMS A 


N. 


28 


NOTIFY 


IMS A forwards the NOTIFY to UE A 








29 


200 OK 


UE A responds with 200 OK 








30 


200 OK 


IMS A forwards the 200 OK response 
to AS A 




31 






















UE receives service attachment 
information 



4.5.7.3 



BC session 



Interoperability Test Description 


Identifier: 


TD IMS IPTV 0003 


Summary: 


IMS network supports properly IPTV Broadcast session. 


Configuration: 


CF IPTV 


BUT 


IMS A 


References 


Test Purpose 


Specification Reference 


TP IMS 5108 03 


TS 124 229 [1], clause 5.4.3.2 HI 


TP IMS 5107 02 


TS 124 229 [1], clause 5.4.3.2 1149 


Use Case ref.: 


UC 19 1 
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Interoperability Test Description 




Pre-test 
conditions: 


• HSS of IMS_A is configured according to table 1 

• UE A has IP bearers established to its respective IMS networks as per clause 
4.2.1 

• UE_A is registered in IMS A using userlPTV according to table 1 

• UE_A has done IPTV registration and service attachment procedures using push 
or pull mode 

• IMS A not configured for topology hiding 


Test Sequence: 


Step 




1 


User A initiates a BC session 


11 


User A receives the broadcast content 


12 


User A terminates the session 


19 


User A is informed that session is terminated 




Conformance 
Criteria: 


Check 


^ 


1 


TP_IMS_5108_03 in CFW step 3 (INVITE) 
ensure that { 
when { lUT receives an initial INVITE from IMS A} 
then { lUT sends the initial INVITE to AS_A 
containing a topmost Route_header 

indicating the SIP_URI of AS_A and 
containing a Route header 

indicating the S-CSCF SIP_URI of IMS_A and 
containing a P-Charging-Vector_header 
including a orig-ioijparameter 

indicating operatorjdentifier of IMS_A and 
not including a term-ioi parameter} 

} 




2 


TP_IMS_5107_02 in CFW step 7 (ACK) 
ensure that { 

when { UEA sends ACK to addressed to UE_B} 
then { IMS_B receives the ACK 
not containing a Route header 

indicating the S-CSCF_SIP_URI of IMS_A and and 
not containing a P-Access-Network-lnfo header 
} 
} 



Step 


Direction 


Message 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

M 
S 
A 


A 
S 
A 


1 

M 
S 
B 


A 
S 
B 






1 




> 


















User A initiates a BO session 


2 












N. 








INVITE 


UE A sends a INVITE to IMS A 


^ 






3 


INVITE 


IMS A forwards the INVITE to AS A 




4 


200 OK 


AS A responds with 200 OK 




5 


200 OK 


IMS A forwards the 200 OK response to 
UE A 






>. 


6 


ACK 


UE A acknowledges the receipt of 200 
OK for INVITE 








7 


ACK 


IMS A forwards the ACK to AS A 




8 
9 




i 

> 


















User A receives the broadcast content 
User A terminates the session 


10 












N. 








BYE 


UE A sends a BYE to IMS A 


^ 






11 


BYE 


IMS A forwards the BYE to AS A 




12 


200 OK 


AS A responds with 200 OK 




13 


200 OK 


IMS A forwards the 200 OK response to 
UE A 








14 






















User A is informed that session is 
terminated 
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4.5.7.4 



CoD session. Establishing content control channel and content delivery 
channels using RTSP Method 1 



Interoperability Test Description | 


Identifier: 


ID IMS IPTV 0004 


Summary: 


IMS network supports properly IPTV content on demand session. 


Configuration: 


CF IPTV 


BUT 


IMS A 


References 


Test Purpose 


Specification Reference 


TP IMS 5108 03 


TS 124 229 [1], clause 5.4.3.2 HI 


TP IMS 5107 02 


TS 124 229 [1], clause 5.4.3.2 1149 


Use Case ref.: 


UC 20 1 




Pre-test 
conditions: 


• HSS of IMS_A is configured according to table 1 

• UE A has IP bearers established to its respective IMS networks as per clause 
4.2.1 

• UE_A is registered in IMS A using userlPTV according to table 1 

• UE_A has done IPTV registration and service attachment procedures using push 
or pull mode 

• UE_A, IMS_A and AS_A are configured to establish content control channel and 
content delivery channels using RTSP method 1 

• IMS A not configured for topology hiding 




Test Sequence: 


Step 




1 


User A initiates a CoD session (content selection) 


26 


User A starts receiving the streaming content 


27 


User A terminates the session 


36 


User A is informed that session is terminated 


^^^^~ 


Conformance 
Criteria: 


Checit 




1 


TP_IMS_5108_03 in CFW step 3 (INVITE) 
ensure that { 
when { lUT receives an initial INVITE from IMS A} 
then { lUT sends the initial INVITE to AS_A 
containing a topmost Route_header 

indicating the SIP_URI ofAS_A and 
containing a Route header 

indicating the S-CSCF SIP_URI of IMS_A and 
containing a P-Charging-Vector_header 
including a orig-ioi_parameter 

indicating operatorjdentifier of IMS_A and 
not including a term-ioi parameter} 
} 


2 


TP_IMS_51 07_02 in CFW step 1 1 (ACK) 
ensure that { 

when { UE_A sends ACK to addressed to UE_B} 
then { IMS_B receives the ACK 
not containing a Route header 

indicating the S-CSCF_SIP_URI of IMS_A and and 
not containing a P-Access-Network-lnfo header 
} 
} 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


u 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

IVI 

s 

A 


A 
S 
A 


1 

M 
S 
B 


A 
S 
B 






1 






















User A initiates a CoD session (content 
selection) 




2 










■N. 










INVITE 


UE A sends a INVITE to IMS A 


^ 






3 


INVITE 


IMS A forwards the INVITE to AS A 
(SCF) 




4 


INVITE 


AS A forwards the INVITE to IMS A 


V 


5 


INVITE 


IMS A forwards tlie INVITE to AS A 
(MF) 




6 


200 OK 


AS A (MF) responds with 200 OK 


N. 


7 


200 OK 


IMS A forwards the 200 OK response to 
AS A (SCF) 


^ 


8 


200 OK 


AS A forwards the 200 OK response to 
IMS A 




9 


200 OK 


IMS A forwards the 200 OK response to 
UE A 








10 


ACK 


UE A acl<nowledges the receipt of 200 
OK for INVITE 








11 


ACK 


IMS A forwards the ACK to AS A 
(SCF) 


^ 


12 


ACK 


AS A forwards the ACK to IMS A 




13 


ACK 


IMS A forwards the ACK to AS A (MF) 


























UE A sets up RTSP with AS A (MF) 


14 




















INVITE 


UE_A sends relNVITE message 
indicating media attribute " a=recvonly " 








15 


INVITE 


IMS A forwards the relNVITE to AS A 
(SCF) 


^ 


16 


INVITE 


AS A forwards the relNVITE to IMS A 




17 


INVITE 


IMS A forwards the relNVITE to AS A 
(MF) 




18 


200 OK 


AS A (MF) responds with 200 OK 


V 


19 


200 OK 


IMS A forwards the 200 OK response to 
AS A (SCF) 




20 




















200 OK 


IMS B forwards the 200 OK response to 
IMS A 


N. 


21 


200 OK 


IMS A forwards the 200 OK response to 
UE A 








22 


ACK 


UE A acl<nowledges the receipt of 200 
OK for relNVITE 








23 


ACK 


IMS A forwards the ACK to AS A (SCF) 




24 


ACK 


AS A forwards the ACK to IMS A 


V 


25 


ACK 


IMS A forwards the ACK to AS A (MF) 




26 
27 


















User A starts receiving the streaming 

content 

User A terminates the session 


i 










> 










28 












V 








BYE 


UE A sends a BYE to IMS A 








29 


BYE 


IMS A forwards the BYE to AS A (SCF) 


^ 


30 


BYE 


AS A forwards the BYE to IMS A 




31 


BYE 


IMS A forwards the BYE to AS A (MF) 


^ 


32 


200 OK 


AS A (MF) responds with 200 OK 




33 


200 OK 


IMS A forwards the 200 OK response to 
AS A (SCF) 




34 


200 OK 


IMS B forwards the 200 OK response to 
IMS A 




35 


200 OK 


IMS A forwards the 200 OK response to 
UE A 








36 




^ 


















User A is informed that session is 
terminated 
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4.5.7.5 



CoD session. Establishing content control channel and content delivery 
channels using RTSP Method 2 



Interoperability Test Description | 


Identifier: 


ID IMS IPTV 0005 


Summary: 


IMS network supports properly IPTV content on demand session. 


Configuration: 


CF IPTV 


BUT 


IMS A 


References 


Test Purpose 


Specification Reference 


TP IMS 5108 03 


TS 124 229 [1], clause 5.4.3.2 HI 


TP IMS 5107 02 


TS 124 229 [1], clause 5.4.3.2 1149 


Use Case ref.: 


UC 21 1 




Pre-test 
conditions: 


• HSS of IMS_A is configured according to table 1 

• UE A has IP bearers established to its respective IMS networks as per clause 
4.2.1 

• UEA is registered in IMS A using userlPTV 

• UE_A has done IPTV registration and service attachment procedures using push 
or pull mode 

• UE_A, IMS_A and AS_A are configured to establish content control channel and 
content delivery channels with RTSP method 2 

• IMS A not configured for topology hiding 




Test Sequence: 


Step 




1 


User A initiates a CoD session (content selection) 


32 


User A starts receiving the streaming content 


^V 




"^^^^^^M" "^^^^^ 


Conformance 
Criteria: 


Check 




1 


TP_IMS_5108_03 in CFW step 3 (INVITE) 
ensure that { 
when { lUT receives an initial INVITE from IMS A} 
then { lUT sends the initial INVITE to AS_A 
containing a topmost Route_header 

indicating the SIP_URI of AS_A and 
containing a Route header 

indicating the S-CSCF SIP_URI of IMS_A and 
containing a P-Charging-Vector_header 
including a orig-ioi_parameter 

indicating operatorjdentifier of IMS_A and 
not including a term-ioi parameter} 
1 


2 


TP_IMS_51 07_02 in CFW step 1 1 (ACK) 
ensure that { 

when { UE_A sends ACK to addressed to UE_B} 
then { IMS_B receives the ACK 
not containing a Route header 

indicating the S-CSCF_SIP_URI of IMS_A and and 
not containing a P-Access-Network-lnfo header 
} 
} 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 


U 

E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

IVI 

s 

A 


A 
S 
A 


1 

M 
S 
B 


A 
S 
B 






1 






















User A initiates a CoD session (content 
selection) 




2 










■N. 






INVITE 


UE A sends a INVITE to IMS A 


^ 






3 


INVITE 


IMS A forwards the INVITE to AS A 
(SCF) 




4 


INVITE 


AS A forwards tlie INVITE to IMS A 


V 


5 


INVITE 


IMS A forwards the INVITE to AS A 
(MF) 




6 


200 OK 


AS A (MF) responds with 200 OK 


N. 


7 


200 OK 


IMS A forwards the 200 OK response to 
AS A (SCF) 


^ 


8 


200 OK 


AS A forwards the 200 OK response to 
IMS A 




9 


200 OK 


IMS A forwards the 200 OK response to 
UE A 








10 


ACK 


UE A acknowledges the receipt of 200 
OK for INVITE 








11 


ACK 


IMS A forwards the ACK to AS A 
(SCF) 


^ 


12 


ACK 


AS A forwards the ACK to IMS A 




13 


ACK 


IMS A forwards the ACK to AS A (MF) 




14 






















UEA starts receiving the streaming 
content 



4.5.7.6 



Request for Network PVR offline capture in home network 



Interoperability Test Description 



Identifier: 



TD IMS IPTV 0006 



Summary: 



IMS network supports properly N-PVR offline capture requests. 



Configuration: 



CF IPTV 



SUT 



IMS A 



References 



Test Purpose 



TP IMS 5108 04 



Specification Reference 



TS 124 229 [1], clause 5.4.3.3 1|1 



Use Case ref. 



UC 22 



Pre-test 
conditions: 



Test Sequence: 



HSS of IMS_A is configured according to table 1 

UE_A has IP bearers established to its respective IMS networks as per 

clause 4.2.1 

UE_A is registered in IMS A using userlPTV according to table 1 

UE_A has done IPTV registration and service attachment procedures using either 

push or pull mode 

IMS_A not configured for topology hiding 



Step 



User A requests to record a live programme that has not started yet 



User A is informed that recording has started 



Conformance 
Criteria: 



Check 



1 



TP_IMS_5108_04 in CFW step 3 (MESSAGE): 
ensure that { 
when { IMS_A receives a MESSAGE from UE_A } 
then { IMS_A sends the MESSAGE to AS_A 
containing a topmost Route_header 

indicating the SIP_URI ofAS_A and 
containing a Route_header 
indicating the S-CSCF_SIP_URI of IMS_A} 
} 
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Step 


Direction 


IVIessage 


Comment 




U 
s 
e 
r 
A 
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E 
A 


U 
s 
e 
r 
B 


U 

E 
B 


1 

IVI 

s 

A 


A 
S 
A 


1 

M 
S 
B 


A 
S 
B 






1 






















User a requests to record a live 
programme that has not started yet 




2 










■N. 










MESSAGE 


UE A sends a MESSAGE to IMS A 


^ 






3 


MESSAGE 


IIVIS A forwards the MESSAGE to 
AS A 




4 


200 OK 


AS A responds with 200 OK 




5 


200 OK 


IMS A forwards the 200 OK response to 
UE A 








6 






















User A is informed that recording has 
started 
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